The BAA
We will sign yours. Most facilities and groups present their own and that is the normal case; we do not insist on our paper. It is signed before any resident data moves, not after a pilot has quietly started.
Where resident data sits
Everything runs in our own AWS account, in a single region, on services AWS lists as HIPAA-eligible and covers under its own business associate agreement. There is no offshore processing and no third-party data warehouse in the path.
- Encrypted at rest. The database volume, the server's disk and the document bucket all have encryption enabled, and the audit-log bucket does too.
- Encrypted in transit, and nothing else is permitted. The database refuses an unencrypted connection outright, and the storage buckets deny any request that did not arrive over TLS. This is a refusal, not a preference.
- Separated by organisation. Every read of your clinical data is scoped server-side to your organisation. A facility identifier from one tenant does not resolve in another's data.
- Audit trail on the account itself. API activity in the AWS account is logged to its own encrypted bucket, separate from application storage.
What the model is shown, and what it is not
The clinical reasoning runs on Amazon Bedrock, inside our account and inside the same HIPAA-eligible boundary as the rest. Prompts are not used to train a foundation model.
Identity items are removed before the model sees anything
A model does not need a resident's name to tell you an order has no supporting note. So the MDS identity items are stripped out of what is sent: resident name, Social Security and Medicare numbers, date of birth, ethnicity and race, and the signature section.
The same discipline runs through the logs. Diagnostic logging records field names and never field values — enough to work out that a record arrived in an unexpected shape, never enough to read a resident out of a log line.
The marketing site and the application are separate, deliberately
The page you are reading carries advertising measurement, because it is a marketing page and no resident data has ever touched it. The application carries none at all — no third-party analytics, no session recording, no advertising pixel. A tracker on a screen showing a resident's name is a disclosure, and the cleanest way to never make that mistake is to never install one.
The two are hosted apart as well. The marketing site is static files only, with no server-side compute of any kind on it, so resident data cannot pass through the hosting that serves this page even by accident. The application talks to its own infrastructure directly.
What we do not claim
There is no SOC 2 report yet
It is on the roadmap and it is not finished, so it is not on the page as a badge. If your procurement process requires a current SOC 2 Type II from every vendor, we will tell you that on the first call rather than on the fourth.
What exists instead is the list above, which is checkable, and a completed questionnaire in your hands within a few days of you sending it.
We also do not claim HITRUST certification, and we do not describe ourselves as "HIPAA certified" — there is no such certification, and a vendor who says there is has told you something useful about the rest of their page.
Access, and getting your data back
- Your PointClickCare access stays yours. It is granted through the Marketplace by your organisation, endpoint by endpoint, and you can withdraw it without asking us.
- Read-mostly by design. The product reads your chart and produces documents you edit and export. It is not a system of record and does not write clinical data back into PointClickCare.
- Exports are yours throughout. Plans of correction and audit output export to Word, during the pilot as well as after it.
Related: What it reads from PointClickCare · Drafting the plan of correction · The 24-hour chart check · The 60-day pilot