Document Generation & E-Signature

Document Generation & E-Signature

Who this is for: doctors, admins, print-station staff, new hires.

The idea

Once a doctor approves a case, the system fills in the official government or medical form for that patient’s state and service, stamps the doctor’s signature onto it, and produces any additional paperwork the case needs (like a prescription, a cover letter, or a shipping label). The finished files are stored securely and made available to the patient and, where relevant, sent on for physical printing.

Step by step

1. The doctor approves the case in the care portal, which triggers document generation for that specific state/service combination.
2. The system looks up the correct blank form template for the patient’s state and service (there are close to 90 different state-specific form templates for parking-placard-style certifications alone, plus separate sets for tinted-window medical exemptions and prescriptions).
3. The system also checks whether this case needs any additional paperwork bundled with it — for example an expiration-date cover letter, a prescription, a physician-credentials sheet, a mailing envelope, or a shipping label — based on the service and state’s configuration.
4. Any previously-generated documents for this case are deactivated first, so only the newest version is ever shown to the patient or sent to print.
5. The blank form is filled in with the patient’s intake answers and the doctor’s medical-judgment fields, matching each answer to the correct field on the form.
6. The doctor’s signature (captured once and reused) is placed onto the form in the correct position for the state’s form layout.
7. The finished document is uploaded to secure cloud document storage, and a record is created linking it to the case.
8. Supporting documents (cover letter, envelope, prescription, physician credentials, shipping label, etc.) are generated the same way and attached to the case as needed.
9. The patient can view/download their finished documents from their dashboard. For services that require a physical copy, the case moves into the printing & fulfillment queue.

Two form-filling approaches used today

• Filling an existing PDF form — used for the official government/medical forms themselves. The system fills in the form’s existing fields and draws the signature image onto the page at the right spot for that state’s layout.
• Building a document from a formatted template — used for supporting paperwork like cover letters, envelopes, shipping labels, physician credentials sheets, and patient agreement documents. These are built from a formatted template (with the case’s details and the doctor’s signature/verification image dropped in) and turned into a PDF.

Signature capture

A doctor’s signature is captured once (drawn digitally) and stored so it can be reused across every document that doctor signs, rather than re-collected each time.

Open questions

• A large-scale internal redesign of this pipeline has been proposed in engineering planning documents (moving from hand-written per-state code to a shared, data-driven system). That redesign is not yet the current system — everything described above reflects what the platform actually does today, not the proposed future design.
• The exact criteria for when a “no-signature” version of a document is produced instead of a signed one was not fully confirmed.

Where this comes from

• parkingmd-care-portal/docs/care-portal-kt-guide.md (Documents & Generation section)
• parkingmd-care-portal/docs/custom-document-simple-guide.md
• parkingmd-care-portal/docs/document-activity-logs.md
• parkingmd-care-portal/src/app/api/generate-med-card/ (main orchestration route)
• parkingmd-care-portal/src/lib/state-forms/ (per-state form fillers)
• parkingmd-care-portal/src/lib/signature/
• parkingmd-care-portal/src/lib/puppeteer/ (cover letters, envelopes, labels, credentials)
• parkingmd-care-portal/src/lib/gcs/ (secure document storage/upload)
• parkingmd-care-portal/src/lib/customDocument/
• parkingmd-care-portal/docs/forms-architecture-blueprint.md (historical/proposed redesign — used only for the open question above, not as fact about current behavior)