LocalChart FAQ

Not as a public download yet. LocalChart is preparing a signed Windows clinic-host installer with guided setup, reliable upgrades and rollback, and release evidence tied to the exact package offered to a clinic. Until that launch gate passes, the website will not present an unfinished build as a public download.

The currently qualified clinic host is Windows. Staff can use current browsers on Windows, macOS, and iPadOS through the clinic's approved HTTPS route. Phone layouts support focused mobile work, but long documentation and front-desk scheduling are better suited to a computer or iPad. Every clinic must validate its actual host, browsers, microphones, and network with fictional patients before clinical use.

Start with the interactive guided tour at https://localchart.app/tour, then email support@localchart.app with the clinic type, approximate provider count, devices, and current documentation workflow. Do not include patient information. A pilot-fit conversation reviews workflow and readiness; it is not a promise of immediate installation or clinical use.

LocalChart helps clinics manage daily work, schedule visits and resources, record or paste visit context, review ordered sources, draft documentation, maintain rehab flowsheets, manage patient memory, import reference records, and export reviewed documentation packets from a clinic-controlled local system.

No. LocalChart can serve as an EMR-lite scheduling and documentation workspace for some cash, wellness, performance, or small therapy practices, and it can also sit beside a cloud EMR as a clinic-owned scheduling, documentation, and records layer. It is not a full practice-management, billing, claims, payment, or payer workflow platform.

A clinic can keep the EMR it already uses for claims, payments, eligibility, patient portals, and payer workflows while using LocalChart for clinic-local scheduling context, visit capture, transcription, fact review, draft documentation, records, and clinician-reviewed exports. This avoids a disruptive replacement project, gives clinicians a focused documentation workflow, and keeps the handoff into the official EMR deliberate and reviewable.

Today, the practical handoff is operator-controlled. LocalChart can import supported copies of schedule, patient-demographic, and reference-record files exported by another system. Authorized users can copy or export reviewed LocalChart documentation for the destination system. For a protected WebPT patient-identity review plan, explicitly assigned staff can prepare and review staged rows without applying them to LocalChart patient records. Exact files vary by EMR and must be tested with synthetic data first. An import is a point-in-time copy. An export or review decision does not automatically file, finalize, or update a chart in the other system.

WebPT import review is a staged review lane for a protected, hash-bound WebPT patient-identity plan. An explicitly permitted preparer chooses the plan and assigns a reviewer. Every row starts on Hold, decisions are limited to Create, Link, Skip, or Hold, and the decision set is encrypted and revisioned. The screen is deliberately review-only: it does not connect to WebPT, does not apply rows to LocalChart patient records, and does not merge or overwrite patient identities. A separate future apply review would be required before any patient-store change.

Connected LocalChart browsers share the host's current LocalChart schedule and records. That is LocalChart synchronization, not live EMR synchronization. Current EMR imports and exports are asynchronous, staff-initiated handoffs: a person chooses when to bring in a supported file or transfer reviewed content. LocalChart does not silently overwrite either system or resolve changes made in both places. A future vendor-authorized API connection could synchronize selected appointments, demographics, statuses, or reviewed note fields only after the clinic, vendor, permissions, field mapping, and audit behavior are validated.

Not by default today. The supported path is to review the content in LocalChart, then copy or export it into the clinic's official system. For the photo-observed WebPT 1.0 workflow, Export places populated high-impact fields first, names the matching WebPT destination, and gives each value its own copy action. The billing-review workspace can prepare service concepts, minutes, proposed timed-unit results, authorization or credential holds, and a manual WebPT handoff summary for assigned human review. WebPT import review can stage protected patient-identity decisions for Create, Link, Skip, or Hold review, but it does not connect to WebPT and does not apply anything to the patient store. The clinician or authorized billing staff member pastes, reviews, saves, signs, submits, and verifies acceptance in WebPT; WebPT remains the final authority. Billing codes, minutes and units, payer-conditional values, signatures, certifications, and attestations remain explicit human decisions. The WebPT 1.0 profile remains partial until a genuine fake-patient walkthrough confirms validation and save/sign boundaries; WebPT 2.0 is not yet mapped. Until a specific integration is built and tested, LocalChart should never be represented as automatically writing back to Jane, WebPT, or another EMR.

One clinic computer is LocalChart's home base, or host. It runs the application and local AI, stores the clinic's LocalChart data, and serves the screens that staff open in a browser over the clinic network. The iPads, Macs, and other PCs do not each need the AI model. If the host is turned off or disconnected, those devices cannot reach LocalChart until it returns. The public LocalChart website is for product information, account/address coordination, and support; it is not where the clinic's charts or recordings are stored.

Short answer: one Windows clinic host runs LocalChart for the whole clinic. Staff computers, iPads, and phones are browser clients and do not need their own GPU. • Fit is not speed: VRAM determines whether the selected workload fits. CUDA-core throughput, GPU architecture, memory bandwidth, cooling, and power determine how quickly the queue clears. • One-provider GPU host: 16 GB system RAM can be workable; 32 GB is the normal recommendation. • Entry GPU host: a qualified 16 GB card in roughly the 4,000-6,000 CUDA-core range is a calculated two-to-four-clinician planning tier. Faster 16 GB cards can serve more people than slower cards with the same VRAM. • Typical clinic host: the measured 6,144-core, 20 GB Ada professional GPU averaged about 7 seconds per ordinary draft and supports a five-to-six-clinician planning target on one managed queue. • Faster clinic host: gaming and professional cards in roughly the 8,000-13,000 CUDA-core range, with adequate VRAM and bandwidth, are calculated five-to-eight-clinician tiers. This includes qualified 16 GB high-performance gaming cards, RTX 3090-class cards, Ada professional cards, and Blackwell professional cards. • Maximum practical clinic tier: RTX 4090/5090-class gaming cards and comparable professional hardware have enough compute for eight or more clinicians on the intended single-queue clinic scale. More expensive flagship workstation hardware is not an ordinary LocalChart requirement. • Measured upper anchor: the RTX PRO 6000 Blackwell averaged 2.3 seconds per ordinary draft with a 3.2-second P95 and completed three simultaneous provider-load requests in about 11 seconds. It is shown as measured calibration evidence, not as an ordinary clinic purchase recommendation. • System RAM: 32 GB is normal. Use 64 GB only as optional headroom for a larger clinic around six to eight or more clinicians, larger imports, or extra background work. • CPU-only fallback: use a current high-end desktop processor, 32 GB system RAM, and NVMe storage. This is primarily a one-provider configuration because simultaneous drafts queue for minutes rather than seconds. • Network and devices: connect the host with 1 Gb Ethernet when practical. Wi-Fi 5 is the normal minimum for staff devices; Wi-Fi 6 or 6E is preferred for a busy clinic. Wi-Fi 4 may be adequate for one or two light-use clients but requires an onsite workflow test. Use current browsers and verify every recording device's microphone. Observed planning measurements use the same bounded synthetic drafting workflow. The measured 20 GB professional GPU completed one provider-load request in about 14 seconds and three arriving together in about 43 seconds. Extending that measured queue slope gives roughly 71-86 seconds for five to six simultaneous requests; that extension is calculated rather than directly measured. The measured high-end CPU averaged about 62 seconds per ordinary draft; its provider-load case took about 111 seconds for one request, 239 seconds for two, and 316 seconds for three. In the 100-report synthetic backlog stress test, the RTX PRO 6000 Blackwell completed 100 of 100 standard reports in 4 minutes 22 seconds, or about 22.9 reports per minute. The CPU attempt completed 29 reports in 30 minutes 6 seconds before stopping; projecting its observed 62.3-second average produces an estimated 100-report time of about 1 hour 44 minutes. The GPU total is measured. The CPU 100-report total is a calculated projection from a measured partial run. Calculated comparisons use CUDA cores, architecture, memory bandwidth, and the measured RTX 4000 Ada and RTX PRO 6000 Blackwell endpoints. They do not assign provider counts from VRAM. The DGX Spark is a future Linux/ARM candidate: its 128 GB unified memory offers unusual capacity, but its 6,144 CUDA cores and 273 GB/s bandwidth do not make it an automatic speed upgrade for LocalChart's short interactive drafts. It requires a separate runtime and portability qualification. NVIDIA/CUDA is the currently qualified Windows GPU path. AMD, Intel, Apple Metal, and other accelerators require their own LocalChart qualification. These figures are planning ranges rather than a compatibility guarantee, and they do not expose LocalChart's internal model, prompt, or test-corpus details.

No. LocalChart provides tools that support clinic review, including local storage, protected-record flags, audit trails, retention-rule status, source confidence, and manual-review holds. The clinic remains responsible for confirming its HIPAA, state-law, payer, malpractice, professional-board, and care-setting obligations. LocalChart output is not legal advice and should not be treated as a compliance certification.

LocalChart uses a Retention Review Center. It can show retention timelines, protected categories, state-rule status, source confidence, and whether legal review is required. Unknown, fallback, deceased-patient, and protected legal-record cases require manual review. LocalChart does not treat retention rules as permission to routinely delete legal records.

Retention rules vary by state, provider type, payer, setting, and clinic policy. Source confidence makes it visible whether a rule is source-referenced or still a conservative fallback awaiting verification. This helps the clinic and legal reviewer see what is known, what is uncertain, and what should not be relied on automatically.

No. Clinician-reviewed notes, submitted intake forms, legal-record audit logs, and similar chart/legal records are manual-review only by default. LocalChart should not make deletion of legal records feel routine.

Retention changes and deletion-sensitive workflows should happen only after backup and recovery checks. Protected-record cases require manual review, and disposition workflows should preserve audit history. LocalChart is designed to remove items from active workflow cautiously, not silently purge legal records.

No. LocalChart does not submit claims, process payments, verify eligibility, connect to clearinghouses, generate CMS-1500s, automate coding, guarantee reimbursement, or run revenue-cycle management. When billing review is enabled, explicitly permitted staff can prepare bounded service-time and unit evidence for an already clinician-reviewed note, route it to an assigned reviewer, and export a manual handoff summary. That workspace is review support only; it does not choose final CPT codes, attest, sign, send data to WebPT, or submit a claim.

LocalChart can prepare a bounded billing-review workspace from an already clinician-reviewed note when a profile has explicit billing preparation access. Suggest From Reviewed Evidence checks same-day reviewed flowsheet treatment rows first and otherwise checks the clinician-reviewed note. It returns code-system-neutral service concepts, therapist or assistant minutes, and bounded clarification questions without returning raw note text. Every suggestion is cryptographically bound to that exact evidence snapshot; if the reviewed source changes, LocalChart requires a fresh preview before preparation. The preparer must review or correct every suggestion. LocalChart then calculates proposed units, encrypts the review, and shows authorization or credential holds. The assigned-review queue lists only work assigned to the signed-in reviewer and names each hold, responsible clinic role, and deterministic next verification action. Reviewers can open their held, ready, or approved work; an export-only profile can open only an already approved or exported review. The exported WebPT summary is for manual human transfer and review, not claim submission or automatic writeback.

The Clinical workspace supports four explicit source types: patient conversation, focused clinician dictation, typed notes, and reviewed handwriting from a photo, scan, or PDF. A note can contain multiple source types without a separate mixed-source mode. Each source remains independently editable, reorderable, replaceable, or removable before drafting.

Transcript & sources shows a flat row for every reviewed source. Up and down arrows change the clinical order. Redo replaces one source, Remove excludes it, and Record more appends another clip to the selected source instead of creating an unrelated block. The combined transcript follows that order and does not insert source labels into clinical text.

Select the patient first, then choose Handwriting. On a desktop, choose Upload photo or PDF. On an iPhone, iPad, or other direct-camera device, choose Take a photo for a new JPEG capture or Choose existing photo or PDF for a supported library file. LocalChart accepts JPEG, PNG, WebP, or PDF, checks page orientation, and prepares editable text. Existing HEIC or HEIF library photos are not supported yet; convert or export them as JPEG before uploading. Compare the original file and text, remove any content belonging to another patient, and choose Add reviewed text to note. Read handwriting again retries the recognition step. The reviewed source remains visible to the clinician. OCR is assistance, not approval, and the clinician must correct it before using it as chart evidence.

Both views use the same reviewed source text. Full Draft is the narrative review path. Review Facts exposes individual statements with their likely source and destination so a clinician can approve, reject, edit, copy, or inspect the source before drafting. A source link is navigation evidence, not automatic clinical approval.

Abandon Test Run is a permanent-deletion workflow for an unapproved draft that should not become a clinical record. LocalChart blocks the action while capture, finalization, or transcription is active, lists what will be deleted, and requires explicit confirmation. The unapproved draft and uniquely owned source files are deleted; reviewed or filed records are not part of this action. This is different from retention or legal-record disposition. Never use it to erase a reviewed note, submitted intake form, audit record, or protected chart artifact.

The flowsheet stores clinician-reviewed structured measures captured from dictation or entered during review. The Exercise Sheet tracks exercise, sets, repetitions or time, resistance, and notes by visit. Historical Measures shows change over time. Structured data supports the note and patient-memory view; it does not replace the clinician's signed narrative.

Yes. The current scheduling workspace includes Day, Stacked, and Week views; provider calendars; location filters; calendar zoom; a compact opposite-side appointment editor; provider availability and PTO; recurring series; classes and clinic events; conflict-checked rooms and equipment; reminders and confirmations; gap filling; provider metrics; a day sheet; schedule-health review; patient booking-change requests; private outbound calendar subscriptions; and external busy-calendar import. Patient-facing booking is request-based. A patient can request a new visit, reschedule, or cancellation through a private link, but staff must review and confirm it before the schedule changes. LocalChart does not submit claims, decide payer authorization, collect payment, or replace a full practice-management system. A clinic using WebPT, Jane, SimplePractice, or another established system should define which system owns each workflow and validate every handoff.

After a clinician-reviewed note linked to a completed scheduled visit is saved, choose Review next visit series. LocalChart first creates a read-only preview from the recorded plan cadence. The preview lists every proposed date and checks the current schedule revision, provider availability, overlap, location, resources, plan end date, and recorded authorization capacity. It also shows warnings such as an unconfigured travel buffer. Nothing is booked during preview. Confirm visit series is available only when the preview has no blockers. Confirmation sends the exact preview identity, schedule revision, and one stable request identity so a retry cannot silently duplicate the series. If the schedule or recommendation changed, LocalChart requires a fresh preview. Staff should still review the resulting visits in Scheduling; this workflow does not make a clinical plan or payer-authorization decision.

Use Today, previous, and next to move the date. Choose Day, Stacked, or Week, filter Location, and adjust Zoom without shrinking the calendar. Find / Go searches commands and appointments already authorized and loaded in the current calendar. More contains Provider Hours, Work Hours, Export CSV, and Print PDF. Schedule Operations opens operational work, and + New Appointment opens a blank editor. Press Ctrl+K on Windows/Linux, Command+K on macOS, or slash while focus is not in a field to open Find / Go. When keyboard focus is not inside a field, T returns to today, D selects Day, W selects Week, N and P move next and previous, and A opens a new appointment for an authorized scheduler. The provider-calendar list supports keyboard reordering. On a phone, LocalChart replaces the multi-row desktop toolbar with a day agenda. Previous day, next day, Today, New, Find, and Operations remain directly available above the flat patient-first list.

Open Find / Go → Find an opening, choose exactly one clinic location, set a date range of up to 31 days, and optionally choose a provider, time window, duration, or conflict-checked resource. LocalChart ranks current gaps and labels openings that need manual review. It also states when travel buffers, plan-of-care windows, or authorization were not evaluated. An eligible result's Prepare button changes the calendar date and opens a prefilled appointment editor. It does not book an appointment, move a patient, contact anyone, or bypass the ordinary conflict and save checks. If the calendar changes after the search, LocalChart discards the stale recommendation and requires a new search.

The compact editor opens on the side opposite the selected time slot so the relevant calendar remains visible. Patient, provider, visit type, date, start, end, and Save Appointment remain primary. Contact and intake, coverage and authorization, and visit settings are flat disclosures. Secondary commands—including Add Another, Fill Queue, Patient History, Start Daily Note, and Delete—are under More actions.

While creating an appointment, turn on Repeat, choose the interval, weekdays, and end rule, review the occurrence count, and save the series. When changing or cancelling a member of a series, choose This visit, This and future, or Whole series. Completed, no-show, cancelled, and documented historical visits are preserved, and a changed single occurrence remains an exception rather than silently rewriting the whole history.

Schedule Operations groups work that should not crowd the calendar toolbar: • Reminders & confirmations shows consent-aware outreach and patient responses. • Fill openings ranks cancellation and waitlist matches by visit need, availability, provider preference, authorization posture, and recorded outreach consent. • Provider metrics summarizes capacity, utilization, confirmations, and outcomes. • Day sheet shows authorization, copay, intake, confirmation, and unsigned-documentation readiness. • Schedule health highlights cadence gaps, expiring authorizations, unresolved cancellations, and documentation backlog. • Online booking requests holds patient requests for staff review. • Locations, resources & calendars manages clinic sites, rooms, equipment, private calendar feeds, and external busy calendars. These are decision-support tools. Staff must verify the source record before making a clinical, payer, employment, or patient-contact decision.

Scheduler Tasks is the flat exception list at the top of Scheduling → Operations. It derives bounded, deterministic work from LocalChart's existing patient, schedule, plan-of-care, authorization, intake, confirmation, cancellation, and documentation facts. It does not create a second patient chart and does not invent clinical need, coverage, authorization, consent, or contact information. Each row explains its priority, source facts, recommended next staff action, recorded channel eligibility, and any suggested opening. Call remains manual. Prepare Email creates a review-only communication job and sends nothing. Book opens the ordinary appointment editor with a suggested opening but does not save it. Staff can record the outcome, snooze, mark the task not needed, or resolve it. LocalChart does not automatically contact patients, determine eligibility, make clinical decisions, or submit billing.

Yes. Authorized staff can define resources such as rooms, treatment tables, and equipment and assign them in Visit settings. LocalChart checks time conflicts and requires the resource to belong to the appointment's location. Resource availability is still only as accurate as the maintained location, hours, and maintenance data.

Authorized staff can create a private subscription URL and add it to Apple Calendar, Outlook, or Google Calendar by URL. The outbound feed excludes clinical detail. LocalChart can also connect to a credential-free HTTPS calendar and import generic busy blocks; staff refreshes it with Sync now. Private subscription URLs should be protected and revoked like credentials. This calendar feed is not the planned offline iOS Provider Daybook. A future companion app will require separate device enrollment, revocation, minimum-necessary snapshot, expiry, and replay protections before it is exposed.

It lets a patient request a new visit, reschedule, or cancellation. It gathers preferences and sends them to the clinic's request inbox. It does not directly book, move, or cancel an appointment. Staff remains responsible for identity, availability, authorization, clinic rules, and confirmation.

Fill openings ranks eligible candidates using recorded visit need, availability, provider preference, authorization posture, and outreach consent. Missing or invalid authorization is held for manual review rather than presented as a confident match. LocalChart does not contact a patient without the appropriate recorded permission and does not make the final scheduling decision.

The day sheet is a compact operations list for each visit's authorization, copay, intake, confirmation, and unsigned-documentation status. It helps staff prepare without opening every patient form. It does not replace the underlying chart, authorization document, or billing system.

Schedule health highlights underbooked plan cadence, authorizations nearing expiration, unresolved cancellations, and documentation backlog. A flag is a prompt to inspect the patient and episode; it is not an automatic plan-of-care, payer, or staffing decision.

The Invoice Support Packet summarizes reviewed clinical documentation and payer, authorization, and visit-reference context for clinic review. It is not a claim, payment request, eligibility check, coding decision, payer-rule output, reimbursement guarantee, or compliance guarantee.

The clinic controls its LocalChart instance and patient-record decisions. LocalChart is designed around clinic-owned local data, explicit review, backup/recovery checks, export, and protected-record handling.

It should not block historical clinical record access, read/export, or legal-record retrieval. A payment hold should affect future paid functionality, not a clinic's ability to access and export prior patient records. A conservative product policy is cancellation/read-only at paid-period end with grace/offline cache, while preserving historical record access/export.

For local clinic use, LocalChart is served by the clinic host over HTTPS. The managed setup assigns a memorable address such as https://wellnessworks.localchart.app that resolves to the host's private LAN address. It is not a public internet patient portal. Localhost HTTP remains acceptable for host-only diagnostics, but plain HTTP on a clinic IP is not a patient workflow route. Routine clinicians, schedulers, front-desk computers, and iPads do not need Tailscale. On the clinic Wi-Fi/LAN they open the memorable https://clinicname.localchart.app address, which resolves directly to that clinic workstation's private LAN address and uses its browser-trusted certificate. Approved remote superusers may optionally use one separately installed, vendor-supported Tailscale client and a clinic-approved private route. LocalChart does not bundle, duplicate, restart, or enroll Tailscale, and it never changes Tailscale or Windows networking automatically. Clinic devices continue to reach the memorable address directly without Tailscale; approved off-site superusers use the same clinic bookmark or the private .ts.net recovery address. Both paths must reach the same production LocalChart host, sessions, and data store. No remote path creates a second production runtime. Public exposure, Tailscale Funnel, plain HTTP, and router port forwarding are not supported patient-workflow routes. Remote setup is an administrator maintenance task with a fresh snapshot, an independent recovery channel, timed automatic rollback, real external application proof, and explicit commit. What does the LocalChart superuser need to do for private remote access? 1. Install and prove LocalChart Production on the clinic LAN first. 2. If remote-superuser access is required, the clinic owner or IT administrator separately installs and enrolls the official Tailscale client. This is not part of the LocalChart installer. 3. In Administration > System Health & Devices, open Remote Access Configuration, choose Set up or Re-configure, and identify a verified second recovery channel. 4. Confirm that the private route and least-privilege access rule name the current clinic host and only the approved remote superusers. A changed host address or access policy requires a new guarded maintenance transaction; do not reuse old network assumptions. 5. Preserve every unrelated Tailscale rule and route, arm restoration of the exact prior state, and make only the one approved change. 6. Prove the original clinic bookmark from a non-LAN enrolled test device with a real authenticated synthetic application workflow. Match its production instance and data identity to a direct LAN proof, then explicitly commit. If proof or commit does not happen before the deadline, the bounded change rolls back. Windows and Tailscale own service recovery. LocalChart reports drift and offers the explicit guarded reconfiguration transaction; it does not silently repair connectivity by restarting Tailscale or changing Windows networking, DNS, forwarding, firewall, default routes, or identity. The committed DNS, single-host route, tailnet policy, and Tailscale Serve state persist independently of LocalChart. LocalChart diagnoses them read-only. Re-configure Remote Access repeats the same snapshot, rollback, proof, and commit safeguards used during initial setup; it does not silently alter workstation networking or DNS.

LocalChart can continue to work during a public-internet outage when the clinic host workstation is running and the clinic's Wi-Fi/LAN is still working. Client devices on that same clinic network can still send data to and receive data from the host. Local records, scheduling, and locally hosted drafting remain inside the clinic network. The clinic router, wireless access points, switches, and local name resolution still need to be available. Remote Tailscale access, public website access, software updates, new public DNS changes, license refresh, new certificate issuance or renewal, and optional off-site sync will not work until internet service returns. The local app uses its most recently cached license window; the account-service outage does not move patient data to the cloud or shut down the local database. Keep a clinic-owned downtime process for workflows that depend on outside services.

Open Clinic Administration > System Health. Start with the four summary blocks, then inspect Active devices. A green host check means only that the host answered; it does not claim that a recording, transcript, or draft completed. Open Recording workflow support and read the stages in order: Browser capture, Server transcript, and LLM draft saved. Stop at the first incomplete stage and follow the displayed support action. Failed or stalled workflows open automatically. Older completed workflows, offline devices, raw events, device IDs, and other technical data remain collapsed until support needs them.

Yes. Once active capture/finalization has safely stopped, the unfinished recording remains encrypted and bound to its original note while the provider opens another patient's note and records normally. LocalChart never inserts the older transcript into the new note. Return to the original note and choose Retry sync to recover it or Discard saved recording if it is an unwanted duplicate. Discard requires confirmation, removes the device-side copy only after the clinic host records the decision, and leaves any host-received evidence under the clinic's normal audit and retention rules. The provider does not need to troubleshoot the older recording while another patient is waiting.

An administrator enters the clinic activation code and chooses an available name in Clinic Administration > System Health > Device connection details. LocalChart reserves the name, connects it to that host's private LAN address, and coordinates a public browser-trusted certificate. A chain can assign separate names to separate clinic sites under one organization. That name is a private clinic route, not a public patient portal. defaultclinic.app is not a LocalChart-controlled domain and should not be used. Use the clinic's assigned LocalChart-managed subdomain or a separately reviewed clinic-owned domain; do not deploy a placeholder name unchanged.

Not when the managed clinic address reports a valid public certificate. Let's Encrypt issues that certificate, so normal current browsers trust it without installing a LocalChart profile. The older root-certificate download remains an advanced fallback for a clinic that deliberately uses a self-managed/private certificate path; do not use that fallback when the managed card says Secure & connected. The clinic browser still must be on the clinic's Wi-Fi/LAN, open the exact assigned address, and sign in with an individual LocalChart profile. The certificate proves the encrypted connection to the assigned host; it does not replace LocalChart login permissions.

At minimum, LocalChart needs a clean reviewed branch, focused auth/retention/provider/patient-identity/runtime tests, a live llama.cpp synthetic-note probe, rendered UI smoke through the clinic workflow, PHI/security proof, backup/restore proof, and a fake-patient pilot simulation. Passing a model benchmark alone is not enough.

The workstation menu bar stays at the top while the page scrolls. File opens new-visit, records, import, and export actions. Admin opens only the workforce, clinic-operations, data, and configuration controls allowed for the signed-in role. View changes palette, density, reload, or full screen. Help opens role dry runs, device setup, the Tailscale superuser guide, FAQ, legal guidance, and About. The profile menu contains billing when permitted, profile switching, and sign-out.

View or Clinic Administration > My settings & training > Appearance offers Follow system, LocalChart light, Lunar, Ocean light, Warm gray, Ocean dark, LocalChart dark, and High contrast. Workspace density can be Comfortable or Compact. The same area controls calendar patient-name order, the default Full draft or Review facts view, and the current browser's human-readable device name.

Open Help > FAQ & Support in the workstation app, or Clinic Administration > My settings & training > Help & FAQ in a browser. Search ordinary words or combine words to narrow the list. Show guidance for filters the current release's topics to Admin, Scheduler, or Provider / PTA. Clear or Escape in the search field resets the query.

An admin uses People & Permissions to create a person with profession, clinical role, displayed credentials, and a temporary password. Existing profiles can be reset, deactivated, reactivated, or signed out from other sessions. Billing preparation, billing review, billing export, billing-rule management, and WebPT import-review permissions are explicit grants separate from ordinary admin, scheduling, subscription, and clinical roles. Signed-in devices lists current sessions. Each person needs an individual profile; shared logins defeat permission and audit boundaries.

Data & recovery contains Storage, Backup & Restore, the Data Safety view, and Retention Review Center. Storage changes require admin reauthentication and explicit confirmation. In Backup & Restore, an admin chooses a separate external drive, network share, or approved cloud-synced folder, then chooses Manual only, Every day, or Every week, the run time, and how many recent routine packages to keep. LocalChart uses the clinic's existing encryption key automatically, writes one encrypted package directly to that destination, verifies it there, and keeps no second routine package beside live data. The screen explains how to validate and test-restore a package and that a separate or off-site copy protects against loss of the clinic computer or live data—not against loss of both the computer and a backup stored only on it. A cloud-sync provider may still keep its own local synchronized copy; its storage and online-only settings are controlled by that provider. LocalChart removes only older current-format packages that are registered to the same clinic and exceed the clinic's chosen limit after a new package succeeds. Recovery previews stage a copy before any live restore. Older v1 backup packages still accept their original passphrase under advanced disaster recovery; legacy packages and renamed owner copies are never removed automatically. Retention timelines do not authorize deletion of protected or uncertain records. Audit & support contains the Settings Change Log, PHI-free support reporting, and report-template management.

LocalChart uses one encryption key for the clinic, not separate keys for each provider. On the new computer's first-run screen, choose Recover an existing clinic and Sign In to Recover Clinic. The primary clinic owner signs in through the central account portal, selects the clinic, re-enters the current password, and approves the one-time code. LocalChart then installs the clinic key into the operating-system-protected key store so the encrypted backup can be restored. Recovery remains available when a trial, payment, or subscription has expired. It still requires a current active primary-owner account; old passwords, disabled accounts, and revoked owner memberships are rejected. A downloaded .lckey file is an offline fallback. Windows BitLocker or Device Encryption is recommended extra stolen-device protection but is not forced by LocalChart.

The intended packaged drafting path is LocalChart-managed llama.cpp. LM Studio can still be useful for development and QA comparisons, but production-readiness evidence should prove that a fake-patient note can be generated through managed llama.cpp without silently falling back to LM Studio.

Pilot pricing is private and available by request. Public-facing material at https://localchart.app should not publish prices until pricing, support expectations, and pilot terms are intentionally approved.

During private pilots, customer billing and bookkeeping should run through Wave invoices or recurring invoices. LocalChart should not collect card numbers, process payments, or store payment credentials. LocalChart may track a manual license status, plan, paid-through date, and grace period for access control. That billing status should never include PHI, patient names, clinical notes, appointment details, or chart content.

No. Real-patient use should stay on hold until setup, profile access, PHI/security readiness, backup/recovery, device route, and fake-patient workflow checks are complete. Demo mode is for testing and training only.

No. LocalChart drafts and organizes documentation for clinician review. Clinicians remain responsible for the final note, missing information, clinical decisions, sign-off, and use of exported records.

For now, support should be handled through the FAQ at https://localchart.app/faq, a support page at https://localchart.app/support, and a help email. Set the public help address before external pilot use, and set LOCALCHART_SUPPORT_EMAIL on the clinic host so the production blocker checklist can confirm that the support route is configured. AI may help draft internal support responses later, but customer-facing replies should be human-approved before delivery. Responses about clinical, legal, HIPAA, billing, reimbursement, payer, or compliance questions should be reviewed before sending and should not promise legal compliance, claim acceptance, reimbursement, or patient-care clearance.

No. The supervised pilot gate and the broad-production blocker checklist answer different questions. A supervised pilot can prove the clinic workflow under controlled conditions, while broad production still requires closing identity, clinic-device HTTPS trust, PHI-vault-primary storage, all-state retention source verification, and support operations blockers.