Digital Forms – Technical Specification

1. Module Purpose & Scope (Authoritative)

Digital Forms is the single system of record for patient documentation and consent within Primoro. It ensures that clinical and administrative information is captured once, that consent is obtained before treatment begins, and that all documentation is structured, validated, and auditable. Digital Forms replaces paper, PDFs, unmanaged uploads, and portal links with a governed, workflow-native system embedded directly into appointments and patient journeys.

It governs:

• Issuing, capturing, and lifecycle-managing structured digital forms for patients and carers
• Enforcing mandatory pre-treatment validation and consent gating
• Generating immutable signed PDF records and handing them off to Document Hub

It explicitly does not:

• Own appointment availability or booking logic — governed by Appointment Manager
• Own messaging or reminder delivery mechanics — governed by Communication Hub
• Own task creation or resolution beyond the trigger event — governed by Task Manager
• Own payments or financial settlement — out of scope for this module
• Author or act as source of truth for clinical records — the PMS remains the clinical record of truth

The aftercare template content block schema supports rich media, specifically inline images and embedded video blocks, as optional components within an aftercare template. These block types are treated as first-class content elements alongside text and structured list blocks, and template authors may include or omit them at their discretion.

Document Hub storage requirements MUST account for aftercare templates that contain media assets. Image and video assets referenced by an aftercare template are stored and versioned within Document Hub under the same governed lifecycle as other form assets, ensuring auditability and consistent retrieval.

It explicitly does not:

• Mandate that any aftercare template include image or video blocks — both types are optional and practice-configurable
• Own video hosting or transcoding — media assets must be supplied in a supported format and are stored as-is within Document Hub

2. Ownership & Responsibilities

2.1 Digital Forms IS Responsible For

• Issuing structured digital forms to patients and carers, including bulk issuance and segmentation
• Capturing legally valid e-signatures with delegated signing attribution (patient, carer, or assisted staff)
• Enforcing mandatory vs. recommended form rules and blocking treatment where mandatory forms are unsigned
• Managing form expiry and re-capture lifecycle (e.g. annual medical history refresh)
• Generating immutable PDF records of signed forms and pushing them to Document Hub at the point of generation
• Providing role-controlled visibility of signed forms to patients and staff
• Maintaining a full, immutable audit trail covering assignment, access, submission, signature, review, download, and override events

2.2 Digital Forms IS NOT Responsible For

• Appointment scheduling or availability — owned by Appointment Manager
• Notification and reminder delivery — owned by Communication Hub
• Task ownership and resolution — owned by Task Manager
• Governed document storage after handoff — owned by Document Hub
• Clinical record authoring — owned by the PMS
• Family relationship definitions and carer authorisation rules — owned by Family Profiles
• Care plan membership creation, modification, or entitlement assignment — owned by Care Plan Subscriptions; Digital Forms may surface plan-relevant form options for staff decision, but it is advisory and data-capture only in that context
• Tenant-level feature flag provisioning or deprovisioning — owned by Admin Control Plane; Digital Forms receives its entitlement state from ACP and does not independently manage tenant enablement

3. Core Objects (Normative)

3.1 Form (Canonical Artefact)

A Form is a governed digital artefact representing one of the following intents: information capture, acknowledgement, consent, or declaration. Forms are not PDFs by default; a PDF is generated only as the immutable signed record at the point of submission.

Minimum required fields:

• FormId (immutable)
• FormTemplateId
• VersionId
• FormType (enum: Medical History | Clinical Consent | Administrative Acknowledgement | Preference / Questionnaire | Marketing Consent | Lead Qualification)
• RequiredStatus (enum: Mandatory | Recommended | Optional)
• Origin (enum: Appointment | Bulk | Manual | AI-Suggested)
• PatientId
• AppointmentId (nullable)
• CarerId (nullable)
• SignedByUserId (nullable — populated when carer or assisted staff signs)
• SignedOnBehalfOfPatientId (always populated)
• SigningRole (enum drawn from Family Profiles relationship model: Self | Parent | LegalGuardian | AuthorisedCarer)
• Status
• SubmissionTimestamp
• ReviewTimestamp (nullable)
• SignedPdfReference (pointer into Document Hub)
• DeclineReason (nullable)
• AuditLog (immutable append-only)

3.2 Form State Machine (Authoritative)

States:

• Assigned — form has been issued to a patient or carer
• Viewed — patient or carer has opened the form (optional, where trackable)
• Submitted / Signed — form has been completed and signature captured
• Reviewed — a staff member has reviewed the submission where review is required
• Expired — form has passed its policy-defined validity window without completion, or the signed version has aged past retention policy
• Superseded — a newer version of the same form template has been issued, replacing this instance

Rules:

• All state transitions are auditable and time-stamped with actor identity.
• A Form MUST NOT return to Assigned or Viewed once it has reached Submitted / Signed.
• A Form in Expired state triggers automatic patient notification via Communication Hub.
• Mandatory forms in any state other than Submitted / Signed block the Surgery Tablet Finish & Send hard stop and block treatment progression.
• Only authorised staff roles (see §9) may manually trigger a Superseded transition; the superseding form instance must be assigned in the same action.

4. Form Assignment & Creation

4.1 Appointment-Driven Assignment (Authoritative)

Forms are automatically assigned based on:

• appointment type
• patient status (new vs. existing)
• clinical policy (e.g. expired or missing medical history)
• procedure codes

4.2 Manual Assignment

Authorised staff may:

• assign additional forms to a patient outside automated rules
• remove optional forms where clinically or administratively appropriate
• request re-completion of an already-signed form with a documented justification

All manual assignment and removal actions MUST be recorded in the audit log with actor identity and reason.

4.3 Bulk Assignment & Segmentation

Forms may be issued in bulk to:

• defined patient cohorts
• time-bounded groups
• compliance or audit populations

All bulk actions are governed and auditable. Bulk operations MUST NOT block the UI; bulk job status must be queryable by administrators after submission.

4.4 AI-Assisted Support (Where Enabled)

Primoro AI may:

• highlight missing or inconsistent patient responses for staff review
• surface risk indicators to the attending clinician
• suggest relevant forms in context (AI Guardian add-on)

AI MUST NOT:

• auto-assign mandatory forms without staff confirmation
• sign or submit forms on behalf of any party
• override clinician or policy-defined form rules

All AI suggestions must be logged against the Form's AuditLog, recording whether the suggestion was accepted or dismissed by the human actor.

4.5 AI Concierge Assignment Channel

AI Concierge is an authorised form-assignment source. Where AI Concierge sends forms as part of a call workflow automation (e.g. booking confirmation or pre-visit preparation), form assignment is routed through Communication Hub for delivery but the assignment record is created within Digital Forms under Origin = AI-Suggested. The call thread context (CallThreadId) MUST be passed as metadata on the assignment event and persisted in the Form's AuditLog, so the initiating call session can be traced from the form record. All AI Concierge-originated assignments remain subject to the AI boundaries defined in §7; no mandatory form may be assigned by AI Concierge without explicit staff confirmation.

4.6 Delegated Signing Attribution (Guardian & Carer Flows)

Where a form is completed and signed by a guardian, parent, or authorised carer acting on behalf of a patient (as authorised via the Family Profiles relationship model), Digital Forms MUST record dual attribution at the point of signature:

• SignedByUserId — the identity of the person who actually signed
• SignedOnBehalfOfPatientId — the patient for whom consent or information is being provided
• SigningRole — the relationship role (Parent | LegalGuardian | AuthorisedCarer), validated against the current Family Profiles authorisation state at signing time

These three fields MUST be immutably locked at the point of signature and MUST be reflected in both the generated PDF and the audit log entry for that signature event. The consent logic applied to the form (e.g. whether the form type permits delegated signing for this relationship and patient age) is enforced by Digital Forms at the point of submission, consuming the authorisation rules provided by Family Profiles via the inbound sync lookup (§6.1). If the Family Profiles authorisation lookup returns no valid delegation for the attempting signer, submission MUST be rejected and the rejection MUST be recorded in the audit log with the reason.

4.7 Care Plan Enrolment Context

Where Care Plan Subscriptions integration is enabled at the tenant level, Digital Forms MAY receive care plan enrolment context for a patient at form assignment time. This context MAY be used to conditionally surface or gate forms that are relevant to a patient's plan membership (for example, plan-specific consent or preference forms). Digital Forms is advisory and data-capture only in this context: it MUST NOT create, modify, or act as the authority for care plan membership or entitlements. Any plan-relevant form assignment driven by enrolment context MUST be recorded in the audit log with the originating enrolment reference. Care Plan Subscriptions remains the enrolment authority; Digital Forms consumes enrolment state but does not write to it.

5. Delivery Surfaces & Access (Authoritative)

5.1 Web Portal

The web portal provides administrative management capability for authorised staff. Staff may review, search, filter, and export form records; manage templates and configuration; perform bulk operations; and access audit logs and compliance exports.

5.2 Tablet App (Surgery Tablet)

Forms and consents are presented as governed steps within the in-appointment workflow on the Surgery Tablet. Outstanding mandatory forms surface as blocking items within the appointment step sequence. The Surgery Tablet Finish & Send hard stop MUST NOT allow an appointment to close while any mandatory form remains unsigned or unsubmitted. Optional and recommended forms that are incomplete at Finish & Send are surfaced as warnings and do not prevent closure.

5.3 Patient Mobile App

Patients and authorised carers can complete, review, download, or securely share signed forms via the patient app. Forms are surfaced pre-visit, in-visit, and post-visit as appropriate to the workflow. Push notification prompts are delivered via Communication Hub. Carer and family delegation is supported per the Family Profiles relationship model.

5.4 Engagement Signals

Digital Forms emits the following signals for staff visibility and analytics: completion rate by form type and appointment type; outstanding mandatory form count per appointment; expiry and re-capture volumes; bulk campaign completion rates; and audit event counts surfaced to the Governance Reporting extension where enabled.

6. Integration Contracts

6.1 Inbound (this module consumes from)

6.2 Outbound (this module emits to)

6.3 PMS Boundary

The PMS remains the source of truth for clinical records. Digital Forms consumes patient demographic and appointment data from the PMS and links signed form records back to the PMS via document reference. Digital Forms does not write clinical record content to the PMS; it only provides document linkage. The exact sync mechanism and field mapping between Digital Forms and the PMS must be confirmed during integration design; see §15.

6.4 Document Hub Immutability Boundary

Signed-form PDFs pushed to Document Hub are version-locked to the signing event upon ingestion. Once Digital Forms has completed a successful push and received the SignedPdfReference, no subsequent lifecycle operation — including annotation, supersession, or re-upload — may alter the original signed artefact. This constraint is enforced by Document Hub and must not be circumvented by Digital Forms or any other module. If a form must be re-completed (e.g. due to content error or expiry), a new form instance MUST be created and assigned; the original signed PDF MUST remain unmodified in Document Hub. Digital Forms MUST NOT attempt a re-push or update of a previously ingested signed PDF reference.

7. AI Boundaries (Non-Negotiable)

This module embeds AI surfaces via the Primoro AI Assistant and the AI Guardian add-on.

AI MAY:

• highlight missing or inconsistent responses in a completed form for human review
• surface risk indicators derived from form content to the attending clinician
• suggest relevant form templates in context (AI Guardian add-on only), subject to explicit staff confirmation before assignment

AI MAY NOT:

• auto-assign mandatory forms without staff confirmation
• sign, submit, or complete any form on behalf of a patient, carer, or staff member
• override mandatory form blocking rules or any clinical policy gate
• bypass governance, access control, or audit requirements
• make commitments on behalf of the practice
• replace required clinical judgement

All AI suggestions (whether accepted or dismissed) must be recorded in the Form AuditLog and reported to the Audit & Compliance log, including the identity of the human actor who actioned the suggestion.

8. Audit & Compliance

The system MUST log all of the following events with actor identity, timestamp, and context:

• Form assignment (automatic, manual, or bulk), including the rule or actor that triggered it
• Patient or carer access (form opened / viewed)
• Form submission
• Signature capture, including delegated signing fields (SignedByUserId, SignedOnBehalfOfPatientId, SigningRole)
• Staff review of a submitted form
• PDF generation and push to Document Hub
• Patient or staff download or secure sharing of a signed PDF
• Form override or decline, with recorded reason
• Form expiry and re-capture trigger
• All AI suggestions, recording which were accepted or dismissed by a human actor
• All bulk assignment job initiations and completions
• All cross-module events emitted or consumed
• Delegated signing authorisation lookups against Family Profiles, including rejections
• AI Concierge-originated assignment events, including the associated CallThreadId
• Care plan enrolment context lookups used to drive conditional form assignment

Audit logs MUST be immutable, append-only, and exportable for inspection by authorised administrators and regulators. Audit log export must support date-range filtering and export by patient, form type, and event type.

9. Access Control

Access is governed via Access Manager using role-based access control. No shared logins are permitted.

Time-bound tablet access is enforced for surgery tablet sessions. Access is revoked immediately on staff exit. MFA requirements for sensitive operations (e.g. audit export, bulk operations) are subject to the Access Manager MFA policy and must be confirmed during integration design.

10. Integration Summary

• Appointment Manager — inbound event (appointment created/updated) triggers automated form assignment; outbound sync query responds with mandatory form status for pre-treatment validation
• Communication Hub — outbound notification events for form assigned, expiring, expired, and re-capture required
• Task Manager — outbound task trigger for outstanding or declined mandatory forms
• Document Hub — outbound signed PDF push at generation; SignedPdfReference returned to Digital Forms; Document Hub governs storage, retention, and access post-handoff; signed artefacts are version-locked on ingestion and may not be altered (§6.4)
• Family Profiles — inbound sync lookup for carer relationship model and delegated signing authorisation; authorisation state validated at point of signature
• Primoro AI Assistant — inbound AI suggestions (AI Guardian add-on); outbound form data for AI context
• AI Concierge — authorised form-assignment source for call-workflow-initiated forms; CallThreadId passed as metadata and persisted in audit log
• Aftercare Manager — outbound signed form reference for post-visit care workflows
• PMS — inbound patient and appointment data; outbound document linkage reference
• Access Manager — RBAC for all read, write, sign, review, and approve operations
• Admin Control Plane — inbound tenant entitlement state; ACP controls whether Digital Forms integration is enabled per tenant; Digital Forms does not independently provision or deprovision at the tenant level
• Care Plan Subscriptions — inbound care plan enrolment context for conditional form assignment where integration is enabled; Digital Forms is advisory only and does not write to plan membership
• Audit & Compliance — immutable event log for all actions listed in §8

11. Explicit Non-Goals

• Messaging and reminder delivery — Digital Forms triggers events; Communication Hub owns delivery mechanics
• Autonomous AI form assignment or completion — any AI action requires explicit human confirmation; autonomous AI operation is prohibited (§7)
• Clinical record authoring — the PMS remains the clinical record of truth; Digital Forms provides documentation and consent only
• Governed post-handoff document storage — Document Hub owns signed PDF retention, access control, and audit after the push event; Digital Forms retains only the SignedPdfReference pointer; modification of ingested signed artefacts is prohibited (§6.4)
• Appointment scheduling and availability — Appointment Manager owns this domain
• Financial settlement — out of scope; no payment module is currently named for this concern
• Care plan membership or entitlement management — Care Plan Subscriptions is the enrolment authority; Digital Forms is advisory and data-capture only in plan-related workflows
• Tenant feature flag management — Admin Control Plane owns tenant-level enablement; Digital Forms consumes entitlement state only

12. Versioning & Governance

This specification is owned by: the Digital Forms module owner.

Changes to this spec require:

• review by the MVP module owner
• impact analysis across all declared related modules (see /propose)
• version bump (patch for clarifications, minor for behaviour changes, major for breaking contract changes)

All changes must preserve: consent before treatment, patient visibility of their own signed documents, full auditability, and separation of concerns between modules.

13. Build Contract (Engineering & QA)

13.1 Canonical Data Model

forms (
  form_id                       UUID PRIMARY KEY,          -- immutable
  form_template_id              UUID NOT NULL,
  version_id                    UUID NOT NULL,
  form_type                     ENUM NOT NULL,             -- Medical History | Clinical Consent |
                                                           --   Administrative Acknowledgement |
                                                           --   Preference/Questionnaire |
                                                           --   Marketing Consent | Lead Qualification
  required_status               ENUM NOT NULL,             -- Mandatory | Recommended | Optional
  origin                        ENUM NOT NULL,             -- Appointment | Bulk | Manual | AI-Suggested
  patient_id                    UUID NOT NULL,
  appointment_id                UUID NULL,
  carer_id                      UUID NULL,
  signed_by_user_id             UUID NULL,                 -- populated when carer/assisted staff signs
  signed_on_behalf_of_patient_id UUID NOT NULL,
  signing_role                  ENUM NULL,                 -- Self | Parent | LegalGuardian |
                                                           --   AuthorisedCarer
  status                        ENUM NOT NULL,             -- Assigned | Viewed | Submitted | Signed |
                                                           --   Reviewed | Expired | Superseded
  submission_timestamp          TIMESTAMPTZ NULL,
  review_timestamp              TIMESTAMPTZ NULL,
  signed_pdf_reference          TEXT NULL,                 -- pointer into Document Hub
  decline_reason                TEXT NULL,
  call_thread_id                TEXT NULL,                 -- AI Concierge call context, where applicable
  care_plan_enrolment_ref       TEXT NULL,                 -- enrolment reference where assignment was
                                                           --   driven by care plan context
  audit_log                     JSONB NOT NULL             -- immutable append-only
)

13.2 Core Behaviour Rules

Numbered list of testable behavioural rules:

1. A Medical History form in any state other than Signed MUST block treatment progression; the Surgery Tablet Finish & Send hard stop MUST NOT complete while this condition holds.
2. A generated PDF MUST exactly reflect the form content at the moment of submission; no retrospective modification is permitted.
3. Form template versions MUST be preserved; a signed form MUST always be retrievable against the exact template version that was signed.
4. All AI suggestions MUST require an explicit human confirmation action before any form assignment or data change is committed.
5. All access events, downloads, and secure shares MUST be recorded in the audit log with actor identity and timestamp.
6. Delegated signing fields (SignedByUserId, SignedOnBehalfOfPatientId, SigningRole) MUST be populated and immutably locked at the point of signature, and MUST be reflected in both the generated PDF and the audit log.
7. Signed PDFs MUST be pushed automatically to Document Hub at the point of generation; the returned SignedPdfReference MUST be persisted on the form record before the transaction closes.
8. Bulk assignment operations MUST be auditable and MUST NOT degrade UI responsiveness for concurrent users.
9. A Form MUST NOT transition back to Assigned or Viewed once it has reached Submitted / Signed.
10. Optional and recommended forms MUST NOT block appointment closure or treatment progression at any point.
11. A delegated signing attempt MUST be rejected, and the rejection recorded in the audit log, if the Family Profiles authorisation lookup does not return a valid delegation for the attempting signer at the time of submission.
12. Digital Forms MUST NOT re-push or update a previously ingested signed PDF reference in Document Hub; any re-completion requirement MUST result in a new form instance.
13. AI Concierge-originated form assignments MUST persist the CallThreadId in both the form record and the audit log at the time of assignment.
14. Digital Forms MUST NOT create or modify care plan membership records; it MUST only read enrolment context from Care Plan Subscriptions.

13.3 Configuration Surfaces

Configurable by practice administrators via the Admin Control Plane:

• Form templates (create, version, archive)
• Conditional logic within form templates
• Expiry rules per form type
• Pre-visit visibility windows
• Signing permissions and delegation rules
• Consent enablement flags (e.g. marketing / social media consent)
• Bulk segmentation rules and cohort definitions
• Care Plan Subscriptions integration enablement (where applicable)

Per-appointment overrides (e.g. adding or removing optional forms) are available to authorised clinical and administrative staff within the Digital Forms module interface, within the boundaries set by practice-level configuration.

13.4 Filtering & Views

Staff views in the web portal MUST support filtering by:

• form type
• form status
• expiry date (upcoming and past)
• linked appointment
• patient or patient segment
• origin (appointment-driven, manual, bulk, AI-suggested)
• audit event type and date range

13.5 Module Extension Map

When the following add-ons or modules are enabled, Digital Forms extends as follows without breaking this contract:

• AI Guardian add-on — enables form relevance suggestions and risk indicator surfacing via Primoro AI Assistant; all AI behaviour remains subject to §7 boundaries
• Care Plans (add-on) — advisory workflows linked to form outcomes; plan membership remains owned by Care Plan Subscriptions
• Governance Reporting — compliance summary dashboards drawing on Digital Forms engagement signals and audit events

13.6 Acceptance Criteria

The build of Digital Forms is complete when:

• [ ] All canonical Form objects can be created, read, and updated through the API
• [ ] State machine transitions enforce all rules in §3.2 and no prohibited transitions are possible
• [ ] Mandatory forms block the Surgery Tablet Finish & Send hard stop until signed (negative test: closure is refused; positive test: closure proceeds after signing)
• [ ] Optional and recommended forms do not block closure at any point
• [ ] Delegated signing attribution fields are populated, immutably locked, and present in the generated PDF and audit log for all carer/guardian-signed forms
• [ ] Delegated signing attempts with no valid Family Profiles authorisation are rejected and rejection is recorded in the audit log
• [ ] Signed PDFs are pushed to Document Hub automatically at generation time and SignedPdfReference is persisted
• [ ] No re-push or update of a previously ingested signed PDF reference is possible
• [ ] AI Concierge-originated assignments persist CallThreadId in the form record and audit log
• [ ] Care plan enrolment context lookups are consumed read-only; no write operations against Care Plan Subscriptions are possible from Digital Forms
• [ ] Tenant entitlement state is consumed from Admin Control Plane; Digital Forms cannot independently enable or disable itself at the tenant level
• [ ] All integrations in §6 are wired and tested
• [ ] AI boundaries in §7 are enforced (negative tests confirm AI cannot assign, sign, or override without human action)
• [ ] Audit log captures every event listed in §8 with actor identity and timestamp
• [ ] Access control is enforced per §9 and no role can exceed its defined permissions
• [ ] All non-functional requirements in §14 are met
• [ ] Bulk operations do not block UI and bulk job status is queryable
• [ ] Patients can view, download, and securely share all forms they have signed

14. Non-Functional Requirements

• Performance: Form loading MUST be instant (target: < 1 second) in appointment context on the Surgery Tablet. Bulk assignment operations MUST execute asynchronously and MUST NOT block the UI for concurrent users. PDF generation MUST complete within a defined SLA to be confirmed during engineering design; see §15.
• Reliability: No form submission or signature event may be lost. Offline tablet handling behaviour (queue, sync on reconnection, or hard block) MUST be defined before build; see §15. The module MUST degrade gracefully if Document Hub is temporarily unavailable — submissions must be queued and the PDF push retried, with the form remaining in a Signed state until the push succeeds.
• Scalability: The module MUST support multi-site, multi-tenant deployments. Bulk operations MUST be designed to scale across large patient cohorts without impacting real-time appointment workflows.
• Security: All form data and signed PDFs MUST be encrypted at rest and in transit. Secrets and key management MUST follow platform-wide policy. No shared login credentials are permitted.
• Privacy: The module MUST honour GDPR data subject rights including access, rectification (where not in conflict with immutable signed records), and erasure (secure deletion where legally permitted). Data retention policies must be configurable per form type by practice administrators, within regulatory minimums.
• Accessibility: Patient-facing form interfaces in the patient app and Surgery Tablet MUST meet WCAG 2.1 AA accessibility standards. Carer-assisted completion flows must be usable without requiring technical expertise.
• Observability: The module MUST export metrics covering form completion rates by type and origin, outstanding mandatory form counts, submission latency, PDF generation success/failure rates, and bulk operation throughput. Structured logs MUST be emitted for all state transitions and integration events. Distributed traces MUST be available for form submission and PDF push flows.

15. Open Questions

Outstanding decisions before this spec can be promoted from draft to published.

1. Offline tablet handling: What is the defined behaviour when the Surgery Tablet loses connectivity mid-form — queue and sync on reconnection, hard block, or another pattern? (Raised in §14 Reliability.)
2. PMS sync mechanism: The exact sync mechanism and field mapping between Digital Forms and the PMS for medical history data and document linkage has not been specified. What are the integration contract details? (Raised in §6.3.)
3. PDF generation SLA: What is the maximum acceptable time for signed PDF generation and push to Document Hub in the appointment context? (Raised in §14 Performance.)
4. MFA policy for sensitive operations: Which specific Digital Forms operations (e.g. audit log export, bulk assignment) require MFA, and is this inherited from Access Manager policy or defined per-module? (Raised in §9.)
5. Offline / async signing for patient app: Can patients complete and sign forms in the patient app when offline, or is an active connection required? If offline signing is permitted, what is the sync and conflict resolution behaviour?
6. Care Plan Subscriptions enrolment context contract: What is the precise API contract (fields, freshness guarantee, error behaviour) for the enrolment context lookup from Care Plan Subscriptions? This must be confirmed during integration design before conditional form assignment based on plan membership is built.