VA Telehealth Room Booking Solution

Executive At-a-Glance

This solution is an enterprise-grade, Power Platform-based system for managing telehealth room scheduling across VA facilities. It replaces legacy spreadsheet-based workflows with a secure, auditable, and efficient application ecosystem. The following metrics represent the current state of the project as of December 2, 2025, reflecting the v0.4.0 Reservation Expirations enhancements.

Capability Matrix

This matrix outlines the core capabilities of the Telehealth Scheduling Solution, their current implementation status, and the key technologies involved.

Solution Packaging Map

The project artifacts are organized for deployment using Power Platform solutions. This map shows how repository contents translate into the deployable package.

pwsh -File .\scripts\pwsh\intake-create-issue.ps1 `
                

Result: Triage turnaround time reduced; standardized metadata improves downstream analytics on reported issues.

Deployment QuickStart for Admins

This is a condensed guide for experienced Power Platform administrators. For full details, see the comprehensive Deployment Guide section.

1. Prerequisites:
   • Ensure target environment is in VA Government Cloud.
   • Required licenses: Power Apps Per User, Power Automate Premium, SharePoint Online.
   • Create three Azure AD groups: `TelehealthCoordinators`, `TelehealthManagers`, `TelehealthAdmins`.
2. Provision SharePoint:
   • Create a new SharePoint Team Site. Note the URL.
   • Using the schemas in /src/sharepoint/, create the `RoomMasterData`, `BookingRequests`, and `ApprovedReservations` lists.
   • Grant the AD groups appropriate permissions on the site/lists (e.g., Members/Coordinators get Contribute, Owners/Admins get Full Control).
3. Import Solution:
   • Navigate to the Power Platform Admin Center, select the target environment.
   • Import the managed solution from /releases/v0.3.3/TelehealthBooking_managed.zip.
   • During import, create/configure connection references for SharePoint and Office 365, authenticating with a service account.
   • Set the `SharePointSiteURL` environment variable to the URL of the site created in the previous step.
4. Post-Import Configuration:
   • Share the "Telehealth Booking App" with the `TelehealthCoordinators` and `TelehealthManagers` AD groups.
   • Turn on the Power Automate flows included in the solution.
   • Run the `Migrate-ExcelToSharePoint.ps1` script to populate the `RoomMasterData` and `BookingRequests` lists from legacy Excel files.
5. Validation:
   • Log in as a test user from the Coordinators group and create a booking.
   • Log in as a test user from the Managers group and verify the approval email/notification is received and functional.
   • Confirm the booking status updates correctly in the SharePoint list and the app UI.

Integration & Connector Matrix

The solution integrates with several key Microsoft 365 services. All connectors are standard, first-party connectors operating within the VA Government Cloud boundary.

Data Model Deep Dive

The data architecture is built upon three core SharePoint Online lists, designed to separate static reference data from transactional booking data. This separation optimizes query performance and simplifies permission management.

List: `RoomMasterData`

Stores the canonical inventory of all schedulable rooms. This list changes infrequently.

• Purpose: Acts as the single source of truth for room attributes.
• Key Columns:
  • `Title` (Text): The primary friendly name of the room (e.g., "Aurora 120").
  • `Building` (Choice): The building where the room is located. Indexed for fast filtering.
  • `Capacity` (Number): The maximum number of occupants.
  • `Equipment` (Managed Metadata/Text): A list of available equipment (e.g., "VTC Unit, Speakerphone").
  • `IsActive` (Yes/No): Allows soft-deleting rooms from the booking UI without data loss.

List: `BookingRequests`

A transactional list that captures all new and pending booking requests. This is a high-churn list.

• Purpose: To stage incoming requests and track their journey through the approval workflow.
• Key Columns:
  • `Title` (Text): Auto-generated summary of the request (e.g., "Booking for Aurora 120 by User Name").
  • `RoomLookup` (Lookup): A lookup to the `RoomMasterData` list, establishing a relational link.
  • `StartTime` (Date/Time): The requested start time of the booking.
  • `EndTime` (Date/Time): The requested end time of the booking.
  • `Requestor` (Person): The user who submitted the request.
  • `Status` (Choice): The current state of the request (e.g., "Pending", "Approved", "Rejected"). Indexed.
  • `Justification` (Text): The business reason for the booking.

List: `ApprovedReservations`

Contains only the finalized, approved bookings. This list is optimized for read-heavy operations, such as displaying the main schedule.

• Purpose: To serve as the performant, authoritative source for the final schedule.
• Key Columns: This list largely mirrors `BookingRequests` but adds audit fields.
  • `ApprovingManager` (Person): The manager who approved the request.
  • `ApprovalTimestamp` (Date/Time): When the booking was approved.
  • `OriginalRequestID` (Number): Links back to the initial item in `BookingRequests` for traceability.

Note: The migration from `BookingRequests` to `ApprovedReservations` is handled by the Power Automate approval flow. This prevents the primary scheduling list from being cluttered with rejected or pending items, ensuring the Power App's main gallery query is always fast and efficient.

Workflow Orchestration (Textual Diagram)

This diagram describes the lifecycle of a booking request from submission to finalization, as managed by Power Automate.

[USER in Power App]
 |
 |- 1. Submits Booking Request (Room, Time, Justification)
 |
 V
[POWER AUTOMATE: "New Booking Request" Flow]
 |
 |- 2. TRIGGER: New item created in `BookingRequests` SharePoint list.
 |
 |- 3. VALIDATE:
 |   |
 |   |- Query `ApprovedReservations` for overlaps (Room + Time).
 |   |
 |   |- IF Conflict Found:
 |   |   |- Update `BookingRequests` item status to "Conflict".
 |   |   |- Send "Conflict Detected" email to USER.
 |   |   '- END FLOW.
 |   |
 |   '- IF No Conflict:
 |       '- Continue...
 |
 |- 4. START APPROVAL (Parallel Branches):
 |   |
 |   |-- Branch A: NOTIFY & LOG
 |   |   |- Get USER's manager from Office 365 Users.
 |   |   |- Log "Approval Started" to audit trail.
 |   |
 |   '-- Branch B: CREATE APPROVAL TASK
 |       |- Use 'Approvals' connector to create "Approve/Reject" task.
 |       |- Assign task to manager identified in Branch A.
 |       |- Wait for manager's response...
 |
 V
[MANAGER in Outlook/Teams]
 |
 |- 5. Receives approval request.
 |
 |- 6. ACTION: Clicks "Approve" or "Reject".
 |
 V
[POWER AUTOMATE: Flow Resumes]
 |
 |- 7. PROCESS RESPONSE:
 |   |
 |   |- IF Approved:
 |   |   |- Create a new item in `ApprovedReservations` list.
 |   |   |- Update original `BookingRequests` item status to "Approved".
 |   |   |- Send "Booking Confirmed" email to USER.
 |   |
 |   '- IF Rejected:
 |       |- Update original `BookingRequests` item status to "Rejected".
 |       |- Send "Booking Rejected" email to USER with manager's comments.
 |
 |- 8. FINALIZE:
     |- Log final status and manager's comments to audit trail.
     '- END FLOW.

*Note: An escalation path (not shown) triggers if the approval task is not completed within the SLA (e.g., 24 hours), notifying a secondary approver.*
    

Performance & Delegation Summary

Application performance is critical for user adoption. The design prioritizes responsiveness through careful data query optimization, a concept known as "delegation" in Power Platform.

• Delegation Strategy: All primary data queries from the Power App to SharePoint are designed to be "delegable." This means the filtering and sorting work is done by the SharePoint server, which is highly efficient. Only the necessary data is sent to the app, avoiding the 500-2000 item limit and ensuring the app works with large datasets.
• Non-Delegable Operations: Operations that cannot be delegated (like searching within complex text or certain date functions) are avoided in primary galleries. Where necessary, they are used on pre-filtered, smaller collections of data that are already in the app's memory.
• Caching with Collections: The app pre-loads semi-static data (like the list of rooms from `RoomMasterData`) into in-memory collections on startup. This avoids repeated queries for the same data, making screen transitions and dropdowns feel instantaneous.
• Optimized Galleries: The main schedule grid is sourced from a collection that is filtered on-the-fly, not directly from SharePoint. This provides a smooth scrolling experience. The collection is refreshed intelligently when data changes are detected.
• Key Delegable Functions Used: `Filter()`, `Sort()`, `LookUp()`, `StartsWith()`.
• Reference Document: For a deeper dive, see docs/powerApps-building-filter-formulas.md.

Security & Compliance Snapshot

The solution is built to meet the stringent security and compliance requirements of the VA environment.

• Hosting Environment: All components (Power Apps, Power Automate, SharePoint) are hosted within the **Microsoft Government Cloud (GCC High)**, which meets FedRAMP High authorization standards.
• Data Sensitivity: The application is designed to be **PHI-free**. It schedules resources (rooms), not patients. User training and documentation explicitly forbid entering patient data into any field.
• Access Control:
  • Role-Based Access Control (RBAC): Implemented using Azure AD Security Groups (`TelehealthCoordinators`, `TelehealthManagers`).
  • App Sharing: The Power App is only shared with these specific groups, not with the entire organization.
  • SharePoint Permissions: Permissions on the SharePoint data lists are also tied to these AD groups, enforcing data access rules at the source.
• Data Loss Prevention (DLP): Power Platform DLP policies are in place to prevent data from being shared with non-approved connectors (e.g., social media, personal cloud storage). Only M365 first-party connectors are allowed.
• Audit Trail:
  • SharePoint's built-in version history tracks every change to booking items.
  • Power Automate run history provides a complete log of every approval workflow execution, including who approved/rejected and when.
• Missing Artifact: The `SECURITY.md` file was not found during analysis, indicating a gap in formal, repository-level security documentation.

Versioning & Release Cadence

A structured versioning and release process ensures stability and predictability.

• Versioning Scheme: The project follows **Semantic Versioning (SemVer)**, in the format `MAJOR.MINOR.PATCH` (e.g., `v0.3.3`).
  • `MAJOR`: Incremented for incompatible, significant production changes (target: `v1.0.0`).
  • `MINOR`: Incremented for new, backward-compatible functionality (e.g., adding the dynamic grid).
  • `PATCH`: Incremented for backward-compatible bug fixes and minor tweaks.
• Current Version: `v0.3.3` (as per `CHANGELOG.md`).
• Release Cadence: The project is currently in a pre-release development phase with rapid iteration. Post-v1.0, a cadence of quarterly minor releases and monthly patch bundles is anticipated.
• Source Control: All changes are tracked in a **Git repository**. The `CHANGELOG.md` file is the authoritative source for the history of changes in each version.
• Release Artifacts: For each release, managed and unmanaged Power Platform solution files are generated and stored in the `/releases/` directory (e.g., `/releases/v0.3.3/`).

Upgrade & Extension Path

The solution is designed to be extensible. Future upgrades can be built upon the existing foundation.

• Adding New Rooms/Buildings:
  1. Add the new room details to the `RoomMasterData` SharePoint list.
  2. The Power App will automatically pick up the new rooms in the booking dropdowns. No code change is needed.
  3. If a new building is added, update the 'Building' choice column in the SharePoint list.
• Modifying Approval Logic:
  1. Edit the "New Booking Request" Power Automate flow.
  2. The logic for identifying a user's manager can be adjusted in the "Get manager (V2)" action.
  3. Escalation paths or multi-tier approvals can be added by inserting new condition or approval blocks into the flow.
• Extending the UI:
  1. Use the Power Platform CLI to unpack the `.msapp` file from `src/power-apps/` into source files.
  2. Add new screens or controls in the Power Apps Studio.
  3. Pack the source files back into an `.msapp` file and commit the changes to Git.
• Integrating with Other Systems:
  • New Power Automate flows can be created to connect booking data to other systems (e.g., creating a ticket in a facilities management system when a room's equipment is reported as broken).
  • The use of standard connectors and a clear data model simplifies integration efforts.

Interoperability & Future Roadmap

Based on the analysis of project documents and current capabilities, the following roadmap outlines potential future enhancements.

Short-Term (Next 1-3 Months)

• Power BI Dashboard Rollout: Finalize and publish the `Utilization.pbix` and `Hines - Provider Productivity.pbix` dashboards for managers.
• Teams Integration: Implement adaptive cards in Microsoft Teams for managers to approve/reject bookings directly within Teams chats.
• Automated Archiving: Create a Power Automate flow to automatically archive bookings from `ApprovedReservations` older than 90 days to a separate archive list, keeping the main list performant.

Mid-Term (3-9 Months)

• VistA Integration (Exploratory): Investigate read-only integration with VistA to cross-reference clinic names (`VistA_ClinicNames.txt`) for more descriptive booking justifications, without pulling any PHI.
• Predictive Analytics: Leverage Power BI's AI capabilities to forecast high-demand periods and suggest optimal scheduling patterns to coordinators.
• Mobile UI Enhancements: Further refine the Power App UI for smaller mobile devices based on feedback from the field.

Long-Term (9+ Months)

• Multi-Facility Federation: Develop a model for deploying the solution to other VA hospitals, with a central Power BI dashboard that aggregates anonymized utilization data from all participating facilities.
• Self-Service Equipment Reporting: Add a feature for users to report broken equipment in a room directly from the app, triggering a Power Automate flow to notify facilities management.
• Full GitOps CI/CD Pipeline: Work with VA IT to establish a fully automated CI/CD pipeline using GitHub Actions or Azure DevOps to pack, version, and deploy solutions from Git to Power Platform environments.

Comprehensive Glossary

Definitions for key terms used throughout the Telehealth Booking solution and its documentation.

ALM (Application Lifecycle Management)

The process of managing an application's development, from design to deployment and maintenance. In this project, it refers to using solutions and source control for Power Platform assets.

Canvas App

A type of Power App that allows for a pixel-perfect, highly customizable user interface, like the main booking application in this project.

Connection Reference

A component in a Power Platform solution that acts as a placeholder for a connection (e.g., to SharePoint). It allows the solution to be deployed to different environments without reconfiguring the connections.

Delegation

The ability of a Power App to process data on the data source itself (e.g., SharePoint) rather than bringing all the data into the app first. This is critical for performance with large data sets.

Environment Variable

A configurable value (e.g., a SharePoint site URL or a manager's email) stored in a Power Platform solution that can be changed after deployment without editing the app or flow code.

FedRAMP (Federal Risk and Authorization Management Program)

A U.S. government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. The solution must be deployed in a FedRAMP-compliant environment (GCC High).

Flow (Power Automate)

An automated workflow that performs actions based on triggers and business logic. Used in this project for booking approvals and notifications.

Managed Solution

A packaged Power Platform solution intended for deployment to production environments. It is locked and cannot be directly edited, ensuring stability and controlled updates.

Publisher Prefix (thb)

A unique identifier (`thb` for Telehealth Booking) automatically prepended to the names of all components within a Power Platform solution, preventing naming conflicts.

SharePoint List

A container for data in SharePoint, similar to a table in a database. Used as the primary data source for room master data and bookings.

New Facility Evaluation Checklist

A checklist for onboarding a new hospital building or facility into the Telehealth Booking System. This ensures all prerequisites are met before go-live.

Phase 1: Data & Configuration

• Identify Building Name and Code.
• Compile a list of all telehealth rooms in the new facility.
• For each room, document: Room Name, Capacity, and available Equipment (e.g., "Polycom Trio", "Dual Monitors").
• Identify the primary approval manager(s) for the new facility.
• Add all new rooms to the `RoomMasterData` SharePoint list, ensuring the 'Building' field is correctly populated.

Phase 2: Technical Setup

• Verify the new approval manager(s) are correctly configured in Azure AD with their own managers assigned for escalation.
• If custom approval logic is needed for the new facility, create a copy of the main approval flow and modify it accordingly.
• Update the Power App's configuration (if any environment variables are used for building-specific settings).

Phase 3: Testing & Go-Live

• Perform end-to-end booking tests for at least three different rooms in the new facility.
• Have the designated approval manager test the approval process via email and/or Teams.
• Test conflict detection by attempting to double-book a time slot.
• Announce the go-live date to all staff associated with the new facility.
• Provide a brief training session or documentation link to the new users.

Evaluation Summary

This document was generated as a result of a comprehensive, automated analysis of the workspace. The findings indicate a mature, well-structured project that adheres to modern Power Platform development best practices.

Strengths

• Excellent ALM Practices: The use of managed solutions, connection references, environment variables, and a dedicated publisher prefix (`thb`) demonstrates a strong commitment to enterprise-grade Application Lifecycle Management.
• Robust Security Model: The architecture correctly separates concerns, using SharePoint for data storage with role-based permissions and Power Automate for handling business logic, which aligns with the principle of least privilege.
• Scalable Data Architecture: The SharePoint list design (`RoomMasterData`, `BookingRequests`, `ApprovedReservations`) is normalized and scalable, capable of handling a high volume of bookings while remaining performant due to delegation-aware app design.
• Comprehensive Automation: The project leverages automation effectively, from PowerShell scripts (`generate-inventory.ps1`) for workspace management to Power Automate flows for core business processes.
• Clear Versioning & Documentation: The presence of a detailed `CHANGELOG.md` and component-specific `README.md` files provides excellent traceability and maintainability.

Areas for Enhancement

• CI/CD Automation: While manual export and commit processes are well-defined, the next step in maturity is a fully automated CI/CD pipeline to reduce manual effort and risk. The "Future Roadmap" section outlines this path.
• Source Control for `.msapp`:** The `.msapp` files are binary. The project should adopt the practice of unpacking canvas apps into their source files (`pac canvas unpack`) so that individual component changes can be tracked in Git.
• Centralized Configuration: While environment variables are used, there is an opportunity to centralize more configuration settings (e.g., notification text, list names) to further improve maintainability.