Field notes for your next visit
How to build an appointment-brief app like VisitQuill
Follow VisitQuill’s public GitHub code from a React interface to a server-side FinchNode connection, then build, test and deploy a focused health-record app.
Begin with a small output you can explain
VisitQuill turns selected condition, medication and lab-observation labels into a personal appointment brief. That is a deliberately small feature boundary. A developer can trace each downloaded line to a selected entry instead of starting with an open-ended attempt to summarize an entire medical history.
The public frontend repository contains the React interface, formatting helpers, content and tests. Read its README and license before adapting it for your own product. The source is an implementation reference; cloning it does not activate a patient connection.
Sources: VisitQuill GitHub repository · Project setup and operating notes
Build the public interface first
The project uses React and Vite, with Node 22.13 or newer specified in its setup. Install dependencies, generate the static build and run the tests. Building before testing matters because the SEO checks inspect the generated files in dist.
The development command starts the local interface. Keep its public pages separate from the private import route, /#/import. A visitor reading a guide should not start a record request.
git clone https://github.com/visitquill/app.git
cd app
npm ci
npm run build
npm test
npm run devTrace the brief through the actual component
In app/view.tsx, selected stores record IDs. The component derives chosen entries from that selection, displays their labels and enables the download once at least one entry is selected. The text output is built from those labels.
To customize the product, start at this boundary. A notes field, a different brief layout or a clearer selection experience can be implemented in the product without pretending that the connection itself generated clinical advice.
Sources: Selection and download implementation · Record formatting helpers
Put the FinchNode connection behind a server
The separate Node service creates the hosted FinchNode connection session, checks its status and retrieves categories granted to that session. The frontend talks to that service; the production API key stays in the server’s environment. The server binds temporary access to the exact site origin.
A business adapting the application should operate its own approved configuration. Review the domain-to-site mapping, category allowlist, return URL and frontend Content-Security-Policy together. Merely deploying a copy of the static frontend does not create an independent connection service.
Sources: FinchApps connection service source · FinchNode API contract
Test the boundaries before enabling connections
The frontend tests cover record formatting, public page discovery and search. The backend’s injected mock tests exercise origin restrictions, scope and session behavior without requiring real medical records. Use those tests to understand the contract before extending it.
- Confirm that unsupported categories are rejected by the server.
- Keep missing source fields visible rather than filling them with examples.
- Check ended sessions and failed authorization, not only a successful response.
- Keep all private workspace routes out of the sitemap.
Sources: Backend security tests
Deploy the product and complete the operator setup
For the static frontend, the documented Render build is npm ci && npm run build with dist as the publish directory. The Node connection service is a separate deployment. A new business must align its registered FinchNode application, purpose, privacy details, server secrets and allowed origin before enabling patient use.
Keep the business’s canonical domain in content/seo.json and add future guides there. The build generates the searchable guide index, related links and sitemap. VisitQuill’s current public site is live, but its patient connection remains pending operator activation.
Sources: Independent business handoff notes · Render configuration
Questions about this guide
Is the website and the connection service one deployment?
No. VisitQuill is a static frontend; its authorized connection runs through a separate Node server.
Can I put a FinchNode API key in a Vite variable?
No. Frontend build variables can be shipped to the browser. Keep production credentials in the backend secret environment.