SomexAI · Policies & Procedures Sign in →
Written for the person who has to fill in a vendor review. Where the answer is "not yet", it says so — you will find that out in week three anyway, and finding out now is cheaper for both of us.
This system holds your institutional documents — policies, procedures, approvals and who acknowledged what. It is not a clinical system. It does not connect to your EHR, and it is not designed to receive patient information.
That single fact answers most of a hospital security review before it starts, and it is why the questions below are shorter than you are used to.
No. It holds policy documents, version history, approval decisions and acknowledgement records — the name of a staff member against the policy they read. There is no patient identifier, no clinical data, and no interface to a system that carries either.
If your own policy documents contain patient examples, that content comes from you; we would rather you removed it, and the same is true of any document system you use.
Our position is no, because no protected health information is created, received, maintained or transmitted on your behalf. We would rather have that conversation early than discover a disagreement at signature, so raise it on the first call and we will put the reasoning in writing for your compliance officer.
Google Cloud Platform, in the United States. The data is yours. Policies, versions and acknowledgement records export to file on request or on exit, and nothing is held back to make leaving harder.
In transit over TLS, and at rest by the underlying Google Cloud storage layer. We have not implemented a separate customer-managed key layer on top of that.
Every document lives under an organisation, and separation is enforced in three places rather than one: database rules that deny all direct client access outright, server-side checks that re-read your membership from the database on every single call rather than trusting the session token, and the interface itself. A request carrying a valid token for one hospital cannot read another's data even if the identifier is guessed correctly.
Yes — SAML 2.0 or OIDC, against Entra ID, Okta, or anything that speaks either. You can also require SSO so that password sign-in is switched off entirely for your organisation, and map your directory groups onto roles here.
Remove them in your directory if you use SSO, or deactivate the membership here. Authority is re-checked from the database on every request, so access ends when the record changes rather than whenever a cached session happens to expire.
Who changed a policy, when, what it said before and after, who approved it, and who acknowledged which version. That record is the product — it is what a surveyor asks for, so it is written on every action rather than sampled.
Seven years by default, configurable per organisation, and you can set it to keep everything forever. A legal hold stops deletion entirely while it is active. Anything aged out is archived to compressed storage and hash-verified before the original is removed, so retention never means "quietly gone".
No SOC 2 report. We have not completed a SOC 2 Type II audit. If your procurement process requires one before signature, we are not a fit today and we would rather say so on the first call than waste six weeks of yours. If you can proceed without one — as most facilities of this size can, for a system holding no patient data — tell us what your review does require and we will complete it properly.
Everything above is deliberate about the difference between "not built" and "built and tested". A document system that oversells its own controls is a strange thing to buy for the purpose of proving compliance.
If your review has a standard form, send it. You will get it back completed, with the blanks left blank where the honest answer is that we do not do that yet.