Consent & Agreement Documents

Consent & Agreement Documents

Who this is for: care-team staff, admins, new hires.

How this differs from the final document

This chapter covers agreement/consent-style documents (for example, treatment consent) — paperwork the platform generates and gets the patient to sign as part of processing their case. It is a distinct thing from the actual government/medical form the doctor signs and delivers to the patient, which is covered in Document generation & e-signature.

How an agreement document is built

1. An admin authors a reusable agreement-document template (a title, rich-text content, and placeholder “macros” like patient name, doctor name, or license number that get filled in automatically). Templates can be scoped per brand and are stored as drafts until published.
2. When a specific patient needs that agreement, the system generates a filled-in copy: it looks up the patient’s (and, where relevant, the doctor’s) details, substitutes them into the template’s macros, and turns the result into a PDF.
3. The generated copy is linked back to both the template it came from and the patient’s own document record, and can record when it was signed.
4. Generation can be re-run/forced for a patient even if a copy already exists, for example to fix a mistake.

Requesting a patient’s outside medical records

A separate but related document type is a release-of-records request: a signed authorization the patient completes so the platform can request their existing medical records from an outside clinic/provider on their behalf. Each request captures, as of the moment of signing: the patient’s own details, the outside clinic/physician’s contact details (including a fax number, since records requests are often faxed), and a link to the signed consent PDF itself. These are tied to a specific case, and staff can look up every records request made for a given case.

Consent tracking in the care-team queues

The entire set of care-team queues described in Care team workflows exists specifically to work these release-of-records requests through to completion — it is not a general case-attention list. A dedicated “Consent overdue” queue specifically surfaces records requests where the patient’s release-of-records consent step is late (still unresolved 5+ days after the request was created, by default) — see that chapter for the full set of statuses and configurable day-thresholds involved.

Open questions

• The exact patient-facing step where consent is captured (e.g. a checkbox during intake vs. a separately signed document) was not fully traced in this pass.
• Whether every case type requires an agreement/consent document, or only certain services, was not exhaustively confirmed.

Where this comes from

• parkingmd-care-portal/src/server/db/schema.ts (agreementDocuments, generatedAgreementDocuments)
• parkingmd-care-portal/src/app/api/agreement-documents/ (route.ts, generate/route.ts, preview/route.ts, [id]/route.ts)
• parkingmd-care-portal/src/app/(main)/admin/agreement-documents/page.tsx
• parkingmd-care-portal/src/app/api/generate-agreement-pdf/route.ts
• parkingmd-care-portal/src/app/(main)/care/consent-overdue/page.tsx
• parkingmd-care-portal/src/app/api/care/requests/route.ts (consentOverdue filter, CARE_SETTINGS_KEYS)
• parkingmd-care-portal/src/app/(main)/care/_components/CareRequestList.tsx, CareSidebar.tsx
• parkingmd-care-portal/src/server/db/schema.ts (medicalRecordRequests)
• parkingmd-care-portal/src/app/api/medical-record-requests/[id]/route.ts, .../medical-record-requests/task/[taskId]/route.ts