Validation Pack (draft)
Goal: Give your quality team what it needs to validate signing in OpenX, and say plainly what is left to them.
NOTE
Draft
This pack is a draft. It is written to the signing design being built now, so much of it is marked coming. A "coming" item is specified but not built. The final text follows once every step of the rollout has landed. Each paraphrase of a regulation here is to be checked against its source (eCFR for 21 CFR Part 11) before publishing. Nothing here quotes a regulation word for word.
What this pack is
OpenX signs a record where it is made. A signature is an append-only record in your workspace's Provenance, kept in your own Azure subscription. It names one person, a meaning (such as Review or Approval), a time, and the exact version of the record it signs.
OpenX has no signing screen of its own. Your app shows the record, sends the person to your own login system, and posts the signature to OpenX. OpenX checks what arrives and refuses what does not hold up.
So the work of a signature is split across four parties. This pack says who does what:
| Party | Who it is |
|---|---|
| OpenX | The platform: it checks each signature, seals it, keeps it, and refuses what fails a check |
| Your app | The app that shows the record and the "you are signing this" moment, and calls OpenX |
| Your login system | The directory your app signs people in with, set up in App Identity |
| Your QA | Your quality unit: it owns the validation, the procedures and the decision |
Vendor data alone is not enough
This pack helps your quality team. It cannot finish their work. MHRA's GxP data integrity guidance (§6.19) says a regulated company cannot rely on a supplier's validation data alone (paraphrase, to be checked against the source before publishing). Your QA validates the signing process as you run it: your app, your login system, your procedures and OpenX together.
Fathym holds no certification for 21 CFR Part 11 or EU Annex 11, and OpenX does not make a workspace meet either rule on its own. OpenX gives you controls that help you meet them. Whether your system meets them is for you and your auditor to decide.
The limit no design removes
OpenX sees that a login happened. It cannot see that a password was typed again.
The login request is made by your app, and your login system answers it. A single sign-on bounce can return a fresh-looking login without asking for the password. OpenX can check the login's time, its person and what it was made for. It cannot check what the person typed.
So your login system or your app must force the login at signing: for example, the app asks for a
login with prompt=login, and the login system honours it. Your validation should test this on your own
login system. The OQ outline has a step for it.
How a signature is tied to its record
This is the design being built (coming). The builder's guide has the detail.
- Every signature rests on a login from your login system, made for that record and that meaning.
- The login carries a fingerprint of the record and the meaning, so it can sign nothing else.
- Each login signs once. A second use is refused.
- Where your app writes the record before the person logs in, OpenX's challenge keeps the tie instead.
- A batch is one login over a list the person was shown, all or nothing.
- Only a named person signs. Jobs, apps and AI calls are refused by name.
- Refused attempts are recorded too.
The proof setting
Each workspace chooses how signers prove who they are, in Environment -> Provenance (coming). There is one default per workspace. A meaning can ask for a stronger proof than the default, never a weaker one.
| Proof | State |
|---|---|
| A login from your login system, tied to the record | The default, being built now |
| A personal signing key | Coming, built after the default |
Every signature records which proof it carried, so it can never pass as more.
Still open
Two questions are not decided yet, and this pack makes no statement on them:
- Whether a person signed in with OpenX's own login (a Team session) may sign.
- Whether a workspace may choose a proof weaker than a login from its login system.
The pack
- Responsibility by clause: who does what for Part 11 §11.10, §11.50, §11.70, §11.100, §11.200, §11.300 and Annex 11 §14.
- Trace from controls to tests: each control, its tests and its test-plan rows.
- IQ and OQ outline: what to install and confirm, and what to run.
- Change notices: what changed in signing, release by release.
- Verify without us: check an export and its signatures on your own machine, with no network and no Fathym account.
Next steps
- Build signing into your app -> Sign records from your app
- Set up the record -> Provenance
- Read and export signatures -> Activity Log
- What is and is not recorded -> Compliance Matrix