Quickstart

Quickstart — ParkingMD Platform Documentation

This wiki explains a healthcare compliance platform used to help patients get medical exemption paperwork (parking placards, medical marijuana cards, FMLA leave certification, tinted-window medical exemptions, and similar documents) reviewed and signed off by licensed providers, then delivered.

Who this is for: clinical/support staff, care-team members, product managers, sales/GTM, and new hires who need to understand how the product works without reading code. It is also written to be useful to future engineers/agents who need a plain-language map before diving into the codebase.

The two apps

The platform is made of two separate applications that work together:

1. The patient portal — the public-facing website patients use to pick a service, answer intake questions, pay, book appointments, upload documents, and message their care team.
2. The care portal — the internal back office used by doctors, care-team/support staff, admins, and print-station staff to review each patient’s request, generate and sign the official document, and get it to the patient.

See System Overview for how these two apps connect and who uses each one.

How to use this wiki

Each chapter below starts with a one-line “Who this is for,” is written in plain operational language (what happens, step by step, who’s involved), and ends with a “Where this comes from” section listing the source files/modules used to verify the chapter — those citations are for engineers/agents, not something patients or staff need to know.

Every internal shorthand term (code names, config keys, vendor names) has been translated into the term staff/patients actually use. If a term’s meaning could not be confirmed in code, it is listed as an open question in the Glossary instead of being guessed at.

Chapters

1. System overview — the two portals, who uses each, how they connect
2. Account access — login/signup, sessions, cross-portal auth
3. Pre-signup eligibility check (“Discover”)
4. Patient onboarding & signup
5. Scheduling & appointments
6. Form filling & form processing — patient intake and care-team review
7. Services catalog — what a “service” is, how it varies by state
8. Guides (help & informational content)
9. Payments, checkout, coupons, upsells
10. Messaging & notifications — email, text, phone, in-app
11. Care team workflows — tasks, queues, follow-ups
12. Provider credentialing & state licensing
13. Care-team tools beyond the portal — helpdesk/CRM integrations, browser extension
14. External partner API
15. Referrals
16. Reviews & feedback
17. Document generation & e-signature
18. Consent & agreement documents
19. Admin, analytics & multi-brand support
20. Printing & fulfillment
21. Glossary & open questions

See the Route Coverage Table for a full audit mapping every route/API folder in both apps to the chapter above that documents it.

Core concept: the “task”

Nearly everything in this platform revolves around one idea: when a patient buys a service, the system creates a case (called a “task” in the code). A case moves through statuses (unscheduled, scheduled, under review, ready for packaging, completed, etc.) as the patient completes steps and the care team processes it. Almost every chapter in this wiki refers back to the case/task as the central unit of work.

Multi-brand note

Both apps are built to run as more than one branded product from the same codebase (different logos, colors, contact emails, messaging providers) — see Admin, analytics & multi-brand support.