Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

Spec: specs/pm/specs/PM-34-EN-01-checkin-kiosk-self-service.md Status: πŸ“‹ Not Started

Overview

Patient self-service check-in kiosk enabling demographics review, insurance card capture, electronic consent signing, copay collection, and arrival notification β€” all from a touch-screen device in the facility lobby.

Integration Points

PM-01 (Patient Registration & Demographics)

  • Direction: PM-34-EN-01 reads PM-01 data
  • Pattern: Direct Supabase query (pm_patients) within PM core
  • Usage: Demographics review step displays current patient info; patient can update address/phone/email which writes back to pm_patients.

PM-02 (Insurance & Eligibility)

  • Direction: PM-34-EN-01 reads PM-02 data
  • Pattern: Direct Supabase query (pm_insurance_policies) within PM core
  • Usage: Copay amount sourced from latest eligibility check. Insurance card capture uploads linked to active policy.

PM-03 (Appointment Scheduling)

  • Direction: PM-34-EN-01 reads and updates PM-03 data
  • Pattern: Direct Supabase query (pm_appointments) within PM core
  • Usage: Patient identified by matching today’s appointments. On completion, appointment status updated to checked_in.

PM-09 (Payment Posting)

  • Direction: PM-34-EN-01 triggers PM-09 payment flow
  • Pattern: Direct Supabase insert (pm_payments) within PM core
  • Usage: Copay collection creates a payment record linked to the appointment/patient.
  • Direction: PM-34-EN-01 reads CL-11 consent requirements
  • Pattern: Platform Integration Layer (@/platform/clinical)
  • Usage: Consent step presents required consents for signing. Signed consent records written via platform layer. Cross-core β€” no direct CL imports.

PF-10 (Notifications)

  • Direction: PM-34-EN-01 publishes notifications
  • Pattern: Platform Integration Layer (@/platform/notifications)
  • Usage: Staff notification on patient check-in completion. Configurable via PM-28.

PF-11 (Document Management)

  • Direction: PM-34-EN-01 writes documents
  • Pattern: Platform Integration Layer (@/platform/documents)
  • Usage: Insurance card front/back images uploaded to pf_documents. FK references on pm_checkin_sessions.

PM-28 (System Configuration)

  • Direction: PM-34-EN-01 reads PM-28 settings
  • Pattern: Direct Supabase query (pm_module_settings) within PM core
  • Usage: Kiosk-specific settings: kiosk_inactivity_timeout_seconds, kiosk_require_copay_collection, kiosk_enabled_steps, kiosk_welcome_message.

Data Flow

Patient arrives β†’ Kiosk idle screen
  β†’ Patient identifies (DOB + last name)
    β†’ Match against pm_appointments (today, status=scheduled)
      β†’ Demographics review (pm_patients read/update)
        β†’ Insurance card capture (pf_documents upload)
          β†’ Consent signing (@/platform/clinical)
            β†’ Copay collection (pm_payments insert)
              β†’ Confirmation screen
                β†’ pm_appointments.status = 'checked_in'
                β†’ PF-10 staff notification
                β†’ pm_checkin_sessions.status = 'completed'

Database Tables

TableOwnerAccess
pm_checkin_sessionsPM-34-EN-01New table
pm_patientsPM-01Read/Update
pm_appointmentsPM-03Read/Update
pm_insurance_policiesPM-02Read
pm_paymentsPM-09Insert
pf_documentsPF-11Insert
pm_module_settingsPM-28Read

Security Considerations

  • Kiosk device uses device-bound session token (not user auth).
  • All queries scoped by organization_id + site_id.
  • No PHI cached on device; all data flows via Supabase RLS.
  • Insurance card images stored server-side only (PF-11 storage bucket with RLS).
  • Consent data accessed via Platform Integration Layer (42 CFR Part 2 compliance maintained).
  • Inactivity timeout clears session and returns to idle screen.

Permissions

KeyDescriptionDefault Role
pm.kiosk.manageManage kiosk device configurationorg_admin
pm.kiosk.view_sessionsView check-in session historystaff, org_admin

Deferred Integration (Phase B+)

  • Hardware SDK integration (barcode scanner, card reader)
  • Device provisioning API (remote registration)
  • Offline queue with service worker sync
  • Biometric patient identification