16. Assumptions and Exceptions

Assumptions and Exceptions Overview

This section identifies the principal assumptions, dependencies, exclusions, and proposal qualifications that form the basis of 3Wrkz's response. It is intended to keep the proposal aligned to the actual Phase 1 award basis defined by VNA, the current-state materials provided to date, and the implementation realities reflected in the RFP, requirements workbook, migration workbook, and vendor question responses.

Unless otherwise stated in the final contract, these assumptions apply to pricing, delivery planning, technical scope, migration scope, support, and post-go-live operations. If VNA issues addenda, materially revises requirements, or provides later-discovered information that changes scope, sequencing, data conditions, third-party dependencies, or compliance obligations, 3Wrkz reserves the right to refine the implementation plan, pricing, and commercial terms accordingly.

Proposal Basis and Phase Boundaries

The proposal is based on the following source materials provided in the procurement:

the VNA Meals on Wheels 2.0 RFP
the VNA MOW 2.0 Vendor Qualifications - Scope Matrix - System Requirements workbook
the MOW 2.0 Data Migration Volume Estimates - Vendor workbook
the VNA MOW 1.0 System Documentation
the written vendor question responses provided by VNA

The proposal further assumes the following phase and scope boundaries:

contract award and firm implementation commitment are based on Phase 1a / MVP only
Phase 1b, Phase 2, and Phase 3 items are acknowledged as real future workstreams, but are not assumed to be automatically authorized, fully defined, or fully estimable at proposal stage
any Phase 1b, Phase 2, or Phase 3 work not expressly included in the final statement of work will require separate scope confirmation, schedule alignment, and commercial authorization
VNA's preferred October 2026 go-live target is treated as a target date, not as an unconditional commitment independent of access, decisions, data readiness, third-party responsiveness, and discovery outcomes

VNA Responsibilities and Project Dependencies

The proposal assumes VNA will provide timely participation and decision support throughout discovery, build, testing, migration, cutover, and support transition. In particular, 3Wrkz assumes:

VNA will assign an internal project manager, technical lead, business-analysis support, and business SMEs from operations, finance, intake, clinical, routing, and IT
VNA stakeholders will be available for requirements clarification, backlog prioritization, workflow review, mapping decisions, UAT, training review, and readiness approvals within project timelines
VNA will provide timely access to its Azure tenant, Azure DevOps organization, Entra ID configuration points, API documentation, role and permission information, report examples, form templates, and existing operational reference materials needed for implementation
VNA will execute required NDA, BAA, and related access approvals early enough to avoid schedule delay
VNA will coordinate introductions, access approvals, and commercial/technical cooperation from incumbent or third-party providers where needed, including Netsmart, Hyland OnBase, Bamboo Health, payroll vendors, telephony vendors, app-store accounts, and any selected routing vendor
client-side decisions that materially affect architecture, data-retention posture, routing product selection, support model, security posture, or production operating model will be made within agreed governance windows

Delivery, Architecture, and Operational Assumptions

3Wrkz's proposal assumes the following baseline delivery and architecture posture for Phase 1:

the preferred hosting model is deployment into a VNA-owned Azure tenant during build, test, and production, consistent with VNA's stated direction
source control, CI/CD pipelines, infrastructure-as-code assets, and work-item tracking will reside in Azure DevOps, and VNA will take ownership of those artifacts at handoff
the solution will include separate development, test/QA, training, and production environments; the training environment is assumed to be refreshed on an agreed cadence using approved representative data rather than maintained as a continuously mirrored live PHI copy
the reporting approach will use a dedicated reporting and analytics layer separate from the operational transaction store, with final semantic-model, ETL, and reporting-tool details refined during discovery
report delivery is assumed to be based on agreed operational and compliance outcomes, report categories, and prioritized outputs rather than automatic one-for-one recreation of every existing Crystal Reports artifact in its current form
mobile support will prioritize delivery, route execution, exception handling, and other field workflows; back-office administration, billing reconciliation, and complex reporting remain primarily desktop or tablet workflows
offline or degraded-mode behavior is assumed to focus on critical mobile and delivery operations rather than full offline parity for every module
any use of AI or ML capabilities in Phase 1 is assumed to be limited to those explicitly approved by VNA and separately governed for HIPAA, data-handling, transparency, and cost implications
configuration and admin tooling commitments are assumed to cover agreed metadata, forms, rules, templates, lookups, permissions, and report parameters; they do not imply unlimited no-code modification of all workflow, integration, or platform behaviors without vendor involvement

Data Migration and Legacy Transition Assumptions

The migration workstream is based on the current migration workbook, RFP requirements, and vendor Q&A. 3Wrkz assumes:

migration scope is limited to Meals on Wheels data needed for Phase 1 operational continuity, compliance, billing support, reporting, and historical access
Netsmart, OnBase / AllDocs, RoadNet, and relevant BOP data are the principal source systems in scope for Phase 1 migration planning
RoadNet migration is limited primarily to active route configuration, active route assignments, stop sequences, depots, and related setup data; historical route-execution data is not assumed to be migrated because VNA has indicated that historical operational records already reside in BOP
document migration focuses on required document categories, metadata, and client associations needed for Phase 1 production use; retroactive OCR and full-text search across archived legacy documents are not assumed in the Phase 1 base scope
VNA's stated 10-year retention obligation may be satisfied through a combination of migrated operational data, migrated selected history, and retained read-only/archive access as approved by VNA; the proposal does not assume that every historical record across the full retention window will be fully transformed into the live transactional model unless explicitly defined and priced
final migrated history windows, document categories, entity lists, reconciliation rules, and archive strategy will be confirmed during discovery after profiling and business review
the Netsmart schema, data dictionary, field semantics, and extract methods are not yet fully documented for the vendor, so the migration plan assumes an early profiling and discovery phase before mappings are finalized
data quality issues already identified by VNA, including duplicate clients, incorrect addresses, orphaned records, inconsistent coding, and legacy exceptions, will require joint review and explicit business-rule decisions; the proposal assumes cleansing responsibility is shared between vendor tooling/process and VNA business validation
the duration and rules of any parallel-operations period remain to be jointly defined during implementation planning

Integration and Third-Party Assumptions

The proposal assumes an API-first, integration-led implementation model, but it also assumes that several Phase 1 obligations depend on third-party cooperation, product selection, or later-discovered interface detail. Specifically:

Phase 1 mandatory integration scope is assumed to cover BOP, Bamboo Health, Business Central GL/export needs, payroll-related data exchange, Entra ID / Azure AD SSO, import/export interfaces, and other integrations explicitly required for Phase 1 operations
Salesforce VP, volunteer-management replacement, deeper telephony integration, and broader volunteer/drop-site modernization are assumed to remain largely in their current-state for Phase 1a unless separately authorized; VNA's Q&A indicates these areas are revisited more materially in later phases
the routing solution is assumed to be delivered through a tightly integrated third-party routing engine selected during discovery, rather than through a custom-built proprietary route-optimization algorithm created from scratch as part of the Phase 1 base scope
payroll integration is assumed to include the data flows and file/interface formats confirmed by VNA and the payroll provider; materially different downstream payroll-processing requirements may affect effort and schedule
payer-specific and clearinghouse-specific billing details are not fully defined in the current RFP materials; the proposal therefore assumes final EDI and billing-interface scope will be refined once finance requirements, payer mix, and current submission methods are fully documented
third-party software licensing, transaction fees, messaging fees, mapping fees, app-store fees, or external vendor implementation charges are assumed to be either existing VNA-owned costs, specifically identified allowances, or separately confirmed commercial items; the proposal does not assume open-ended absorption of unknown third-party charges

Support, SLA, Security, and Continuity Assumptions

The proposal assumes the following support and operational posture:

the 24/7 support requirement is interpreted to mean 24/7 on-call coverage for critical incidents, with normal business-hour or next-business-day handling for non-critical issues according to final severity definitions
the frontline support model may be delivered through a specialized support partner with 3Wrkz retaining responsibility for escalated application, integration, reporting, and technical support
the required 90-day warranty period after go-live is included; support structures after the warranty period will transition to the agreed steady-state model
uptime commitments, response targets, maintenance windows, incident severities, and service-credit mechanics will be finalized in contract/SLA negotiations
the availability target is assumed to be measured in a commercially standard manner that excludes approved maintenance windows, force majeure events, upstream cloud-provider outages outside 3Wrkz's control, and client-caused or third-party-caused outages
the RTO and RPO posture will depend on the final hosting architecture, data-replication pattern, approved budget, and any on-premises replication requirements confirmed during design
annual disaster-recovery testing is assumed to be a coordinated vendor-led activity with VNA participation and review, performed within the agreed support or managed-services model
security controls are assumed to be implemented through Azure-native services, application-layer controls, role-based access, logging, encryption, secrets management, and documented operational procedures consistent with a HIPAA-regulated solution
Entra ID / Azure AD automatic user provisioning depends on VNA's identity configuration, licensing, and security policies; if VNA's environment cannot support direct automated provisioning, an agreed alternate onboarding pattern may be used
any on-premises landing zone required for a replicated local data copy will be provided, secured, and connectivity-enabled by VNA unless separately scoped as vendor-managed infrastructure

Pricing and Commercial Assumptions

The commercial basis of the proposal assumes:

Phase 1a is the only phase proposed as a firm implementation commitment at award
Phase 1b, Phase 2, and Phase 3 pricing, if shown, is directional or separately authorizable unless expressly identified as committed scope
where the preferred VNA-tenant Azure model is used, Azure consumption is assumed to remain a direct VNA cost even if the proposal includes modeled hosting estimates for TCO comparison purposes
cloud consumption, Power BI licensing, Entra/M365 licensing, routing-engine licensing, payer or clearinghouse fees, telephony fees, and other third-party charges are assumed to be paid directly by VNA or through existing arrangements unless the proposal expressly includes specific allowances or commercial items for those costs; the proposal does not assume open-ended absorption of unknown third-party charges
any nonprofit pricing, giveback allowances, or preferred pricing treatment described in the proposal is contingent on the final contracted scope and commercial model
intellectual-property, source-code, commercialization, open-source, and resale rights will be governed by the negotiated commercial agreement and the separate commercialization/IP section of the proposal

Exceptions and Deviations from RFP Requirements

To avoid overstating commitments, 3Wrkz identifies the following proposal exceptions, qualifications, or deviations from the broadest possible reading of the RFP/workbook materials:

Phase 1 commitment boundary
3Wrkz is proposing firm implementation commitment for Phase 1a / MVP only. Phase 1b, Phase 2, and Phase 3 are not assumed to be committed, fully defined, or automatically funded at award.
Multi-tenant and SaaS posture
Phase 1 will be designed to be multi-tenant-aware, but the base award posture is a single-tenant VNA deployment. The proposal does not represent Phase 1 as full delivery of the Phase 3 commercialization model.
Routing solution approach
The proposal assumes an integrated third-party routing engine. It does not include custom development of a proprietary route-optimization engine from scratch as part of the base Phase 1 commitment.
Volunteer management and drop-site scope
Based on VNA's written clarifications, volunteer-management and drop-site functions remain substantially in BOP / Salesforce VP during Phase 1a and are not assumed to be fully replaced in the base scope.
Historical migration posture
Historical RoadNet route-execution data is excluded from migration. Legacy document OCR and full-text search across archived OnBase / AllDocs content are also excluded from the Phase 1 base scope.
Retention versus full live conversion
VNA's retention obligation is not interpreted to require full live conversion of every retained historical record into the new operational schema. Archive, read-only, or retained-history approaches are acceptable if they meet agreed operational, audit, and compliance needs.
Certification-related requirements
The proposal commits to a HIPAA-aligned, Azure-based security and compliance architecture. However, the proposal does not represent the custom MOW 2.0 application as an already certified CEHRT, HITECH-certified, or ISO 27001-certified product at proposal stage. If VNA requires formal product or organizational certifications beyond the hosting-provider attestation path and standard contractual/security commitments, those obligations will require explicit contractual treatment.
SOC 2 interpretation
For infrastructure controls, 3Wrkz assumes reliance on Microsoft Azure attestation where permitted by the RFP and qualification-gate language. The proposal does not separately represent that 3Wrkz already holds independent full-product SOC 2 certification for the custom MOW 2.0 application unless expressly provided elsewhere.
On-premises real-time database copy
The requirement for a real-time local/on-premises database copy is conditioned on VNA providing an appropriate secure landing zone, connectivity, security approvals, and operational prerequisites. If those prerequisites are unavailable or impractical, 3Wrkz may propose an equivalent Azure-based reporting or recovery pattern for VNA review.
Device-agnostic interpretation
"Device-agnostic" is interpreted in accordance with VNA's written clarification: phone-first optimization for driver and volunteer field workflows, tablet/desktop support for back-office operations, and desktop-primary treatment for administration, billing, and complex reporting.
Support forums interpretation
The requirement for community forums is interpreted as satisfaction through a structured knowledge base, help materials, user guidance, and support documentation unless VNA specifically requires a broader externally facing community-forum product.
SLA and compensation mechanics
Final SLA remedies, any service credits, and any downtime-compensation mechanics remain subject to contract negotiation. The proposal does not assume uncapped penalties or open-ended indemnification tied to uptime or response commitments.
Accessibility evidence timing
The solution target remains alignment to WCAG 2.1 AA, but the exact form of any VPAT, third-party accessibility audit, or equivalent evidence depends on the final component set, delivery timing, and agreed compliance deliverables.
Third-party and incumbent cooperation
Any requirement materially dependent on incumbent-vendor cooperation, proprietary schemas, licensing rights, or third-party implementation support is conditioned on timely access and commercially reasonable cooperation from those providers.

These assumptions and exceptions are intended to make the proposal precise, commercially responsible, and aligned to the actual Phase 1 award basis rather than implying broader commitments than the current RFP record safely supports.

On this page