1. Who and what this covers
This policy describes how Form Packet ("we", "us") handles information in connection with the Hold Packet packet builder: this website, the application served from it, and any offline build separately provided to a site (together, the "Service").
This is an independent project. It is not affiliated with, endorsed by, or operated on behalf of any state behavioral health agency, any judicial branch, or any hospital, health system, or government agency.
If you use the Service in the course of your employment, your employer's own privacy, security, and records policies also apply to what you do with the packets you produce. This policy covers our side only.
2. Patient information
This is the section that matters, so it comes first and it is unqualified:
How that works
The packet builder runs entirely in your browser. Blank BHA form PDFs are downloaded to your device, and everything you type is merged into them locally, on the machine you are sitting at. The finished packet is produced on your device and saved wherever you choose to save it.
Patient details exist only in the browser tab's memory while you work. They are not written to disk, not placed in local storage, not cached, and not recoverable after the tab is closed or reloaded.
How that is enforced
The claim above does not rest on our good behaviour. Every page of this site is served with a Content Security Policy that permits the page to make network requests to this site and to nowhere else. That restriction is applied by the browser, before any request is made — not by us, and not by anything a flaw in our code could talk its way around. The same policy forbids third-party scripts, so no analytics product, tag manager, session recorder, or advertising pixel can run here, accidentally or otherwise.
The application is additionally covered by an automated test that drives a synthetic patient record through the whole packet-building path and fails the build if any part of it reaches anything transmitted or stored. A failing test blocks deployment.
The third-party exception, and where it does not apply
The contact form and the access-request form carry an anti-spam check (Cloudflare Turnstile) so that automated submissions do not reach a human inbox. It is the only third-party code on this site, and those two public pages are the only place it runs — not the packet builder, not the sign-in page, not anywhere else. It sees only what a bot check needs, which is browser and connection signals rather than the contents of the form. The rule that prevents a page sending data to another origin is not relaxed for it on those pages or on any other.
The contact endpoint accepts only public feedback and reply details, after the sender confirms the message contains no patient information. A separate signed-in beta-feedback form accepts product ratings and an optional comment under the same no-patient-information rule.
Two things a hosted tool cannot claim
Everything above is about what we never receive. Two things are still true of any website, including this one, and we would rather state them than let you discover them:
- Our host sees that you visited. Serving a web page requires receiving a request. Our hosting provider records the IP address, timestamp, and requested URL, as described in section 3. It never sees a patient detail — but "nobody knows this page was opened" is not something a hosted tool can promise.
- Integrity depends on the host. A compromised host could in principle serve different code than the one described here. This is mitigated — every asset is content-hashed, builds are reproducible from a tagged commit, and nothing is published that has not passed the full test suite — but it is a different trust argument from a file that cannot change underneath you, and it should be weighed as one.
If either is unacceptable in your setting, raise it with us before deploying the tool there rather than after.
3. What this site does collect
Server logs
This site is hosted on Cloudflare Pages. As with any website, our hosting provider processes technical request data in order to deliver pages and to protect the site from abuse:
- IP address
- Date and time of the request
- The URL requested
- Browser user-agent string and referring page, where the browser sends them
We do not use this data to build profiles of users, and we do not combine it with account information for any purpose other than investigating abuse or a security incident. We run no analytics product of any kind — there is no Google Analytics, no Plausible, no heatmap, no session replay, and no advertising or tracking pixel on any page of this site.
Account information
If your site has been given access and you sign in, we store the information needed to run the account and the staff directory:
| What | Why |
|---|---|
| Work email address | Identifies the account and receives your sign-in code. |
| Full name, professional credentials, title, role | Fills your own details into the forms, and lets a colleague select you as a certifier. |
| Professional license number | A required field on several BHA forms. Stored so it is not retyped. |
| Your organisation and site | Determines whose roster you can see. Every query is scoped to it. |
| Sign-in codes and session tokens | Stored only as cryptographic hashes, never in a form we could read back. Codes expire in ten minutes and are destroyed on use. |
| An account activity record | Sign-ins, roster changes, and administrative actions, so a site can answer who did what. Contains no patient information. |
| Approximate last-seen date | Identifies dormant accounts. Recorded no more than once a day. |
| A usage record for each packet you generate | Packet type and how long it took, so a site can see whether the tool is being used. Named to your account. No patient information — see below. |
| Beta feedback you submit | Ease rating; whether generated pages, court submission, and Media-tab upload worked; and an optional product comment. Named to your account and required to exclude patient information. |
All of this describes clinicians, not patients. It is professional identifying information of the same kind that appears on a signature line or a hospital badge.
Contact and feedback
If you use the contact form, we receive the name you optionally provide, your reply email address, the topic you choose, and the message you write. The packet builder may also request brief beta feedback after several generations. That response is tied to your staff account so site administrators can investigate an issue. Both forms require you to confirm that the message contains no patient information.
We do not sell it, rent it, share it for advertising, or disclose it to anyone outside the service providers listed in section 7, except where we are legally required to.
4. What is stored on your device
Some things are kept in your browser's local storage so the tool is usable more than once. These never leave your device, are readable only by this site in this browser profile, and are not synchronised anywhere:
| Stored locally | Contains patient data? |
|---|---|
| Saved staff and facility profiles | No — clinicians and hospitals |
| Saved signature images | No — the signer's own signature |
| Light/dark theme preference | No |
| Quality-improvement measurements | No — de-identified when recorded |
| Usage records waiting to be sent | No — packet type and timings |
| Cached blank BHA forms and the site's own code | No — blank forms only |
| Cached staff roster for your site, when signed in | No — colleagues, so the picker works offline |
Patient details are deliberately not on this list. They are held in memory only and are never written to your device's storage.
Signing out erases all of it. Everything in the table above, the cached copy of the application, and the session cookie are destroyed when you sign out — so a shared workstation is left holding nothing this site put there. One consequence is worth knowing before you rely on it: because the offline copy goes too, the next sign-in on that machine needs a network. On a shared workstation, sign out. On a dedicated one that has to keep working through an outage, closing the browser already leaves no patient data behind.
Quality-improvement measurements
The tool records measurements about its own use — how long a packet took, which validation errors were caught, whether a packet was accepted — so that whether it actually helps can be answered with evidence. These are de-identified at the moment they are recorded: they describe events and durations, never a patient. They remain on your device and are transmitted nowhere. They leave only when an administrator exports them, at which point the resulting file is yours and goes wherever you send it.
Nothing about measurement appears on a generated packet. The forms you produce are what they would be if none of it existed.
Usage reporting
One short usage record is sent automatically when you generate a packet while signed in. Your site is told which packet type it was, how many forms and pages, how long it took, how many attempts, whether it was practice, and which account produced it. That is the whole of it: there is no field for a name, date of birth, medical record number, address, county, or date of care. If the workstation has no network the record waits there and is sent later.
This does name you. An administrator at your site can see how many packets you produced and how long each took. It is there so a site can tell whether the tool is reaching the people who need it, and it is not a performance measure — a packet that took longer is far more often the harder case than the slower clinician.
Clinician beta feedback
You can submit this form from the app sidebar at any time. By default, after the first three non-practice packets and every ten thereafter, the application requires it before the next generation; site administrators can change both intervals. It asks whether generated pages, court submission, and Media-tab upload worked and how easy the tool was to use. The response is tied to your staff account so a site administrator can follow up. Written comments are optional unless an issue is reported, and the form requires confirmation that they contain no patient information.
5. What is never collected
- Patient names, dates of birth, addresses, medical record numbers, or any other patient identifier
- Any clinical content — findings, diagnoses, statements, or the contents of a completed form
- Generated packets, or any part of one
- Keystrokes or clinical form-field contents from the packet builder, screen recordings, or session replays
- Location data beyond the coarse geography implied by an IP address at our host
- Anything at all from advertising or analytics networks, because none are present
6. Cookies
This site sets no advertising, analytics, or tracking cookies. There is no cookie banner because there is nothing to consent to.
Signing in sets exactly one cookie: a session cookie that keeps you signed
in. It contains an opaque random token — no personal information is encoded
in it — and is set HttpOnly (unreadable by scripts),
Secure (sent only over HTTPS), and SameSite=Lax
(not sent from other sites). It expires after thirty days, and signing out
destroys it on both ends along with everything else this site has stored
on the device.
7. Service providers
Two providers are involved in operating the Service. Neither receives patient information, because neither is in a position to: patient information never leaves your browser.
| Provider | Role | What they receive |
|---|---|---|
| Cloudflare | Hosting, content delivery, the database backing the staff directory, and the anti-spam check on the contact and access-request forms | Request metadata as in section 3; account records as in section 3, stored in their database service; for the anti-spam check, browser and connection signals from the two form pages — never the contents of the form |
| An email delivery provider | Sends sign-in codes and delivers contact-form messages | Your work email address and sign-in code when signing in; the reply address and message you submit when using the contact form |
We use no other processors. No data is sold or shared with any party for advertising, analytics, or any commercial purpose.
8. How long things are kept
| Data | Kept for |
|---|---|
| Patient information | Never stored. Discarded when the tab closes. |
| Sign-in codes | Ten minutes, or until used — whichever is first |
| Session records | Thirty days, or until sign-out |
| Account records | While the account is active, and until deletion is requested or your site's access ends |
| Account activity records | Up to two years |
| Contact and feedback messages | Only as long as needed to review, reply, and maintain the resulting correspondence |
| Host request logs | As retained by our hosting provider under their own policy — a short window, typically days |
| Locally stored data | Until you sign out, or until you clear it. It is on your device and under your control. |
9. Security
- All traffic is served over HTTPS.
- There are no passwords to steal, reuse, or leave on a shared workstation. Sign-in is a single-use code sent to your work email.
- Sign-in codes and session tokens are held only as hashes, never in a form we could read back. Codes expire in ten minutes and are destroyed on use; the session cookie cannot be read by any script.
- Every database query is scoped to the organisation carried by your session, so one site cannot see another's roster.
- Signing out erases everything this site has stored on the device, and the pages behind sign-in are never written to your browser's disk cache.
- The strict Content Security Policy described in section 2 sharply limits the damage any code-injection flaw could do.
No system is perfectly secure, and we will not claim otherwise. What we can say is that the highest-consequence data in this domain — patient information — is not in our custody at all, which is the strongest security property available and the reason the tool is built the way it is.
If you believe you have found a security issue, please use the contact form before disclosing it publicly. Reports are welcome and will be answered.
10. HIPAA and business associate status
The packet builder does not transmit, store, or otherwise make protected health information available to us, and the separate contact form is not intended or authorised for patient information. On that basis we do not create, receive, maintain, or transmit PHI on behalf of a covered entity through the Service as designed, and we do not act as a business associate under HIPAA for that use.
We are stating our position and the architecture it rests on, not giving you a legal conclusion. Your institution's privacy officer is entitled to reach their own, and we would rather they examine it than accept it. We will answer questions from a privacy or security office directly, and the technical claims here are verifiable from the served application — the Content Security Policy is visible in the response headers of any page on this site.
A fuller treatment — the regulatory analysis in detail, a complete inventory of what is transmitted and stored, the workstation configuration we recommend, and instructions for verifying every claim yourself — is at /security, available once you are signed in. If you are assessing this tool on behalf of a site and have no account yet, write to us and we will provide it.
Note that your use of the tool does involve PHI: the packets you generate are records about a patient, on your device and under your institution's control. Handling those is governed by your employer's policies, not by ours.
11. Your choices
- See or correct your account details. Your own name, credentials, title, and license number are editable in the app, and are the only account information about you that we hold.
- Delete your account. Write to us and we will remove your account record and end your sessions. Note that your name may remain on packets already filed — those are your institution's records, not ours, and we have no access to them.
- Clear local data. Clearing this site's data in your browser removes saved profiles, signatures, measurements, and cached forms from that device.
Depending on where you live you may have additional rights over your personal information — to access it, correct it, delete it, or object to its processing. Write to us and we will honour them. Given how little we hold, these requests are usually simple to answer.
The Service is intended for use by clinicians in a professional capacity. It is not directed to children, and we do not knowingly hold account information about anyone under 18.
12. Changes to this policy
If this policy changes, the effective date at the top changes with it, and the previous text remains in the project's public version history. Changes that would materially reduce the protections described in section 2 will be announced in the application itself before they take effect — that section is the reason people trust this tool, and it should not be able to change quietly.
13. Contact
Questions about this policy, requests concerning your information, and enquiries from institutional privacy or security offices:
Use the contact and feedback form
Please do not include patient information in correspondence with us.