Independent Verification of Consent Documents

Last updated: 26 June 2026

This paper explains how anyone — a patient, a solicitor, a regulator, an expert witness or an opposing party — can confirm, without our help and without trusting us, that a Get Patient Consent document is genuine and has not been altered since it was signed.

It is written in two layers. The first part explains the trust model in plain language. The second part gives the precise technical procedure, using standard, freely available tools, for anyone who wants to carry out the check themselves.

What this proves, and what it does not. Verification proves the integrity, authorship and timing of the record: that this exact content was sealed by Get Patient Consent at a known time and has not changed since. It does not, by itself, prove that the consent was clinically valid. Valid consent depends on the patient having capacity, being appropriately informed, and deciding voluntarily — that remains a matter for the treating clinician and the patient. The record is designed to evidence that process, not to replace it.

Part 1 — The trust model in plain language

The signed record is the data, not the PDF

A Get Patient Consent document is not, at its core, a PDF. The authoritative record is a structured data file (in JSON format) that captures exactly what the patient was shown, what they declared, who they are, how their identity was checked, when each step happened, and who countersigned. The PDF and the on-screen pages are human-readable views of that data.

This matters because it is the data that is cryptographically sealed. The PDF simply carries a copy of that sealed data inside it. If anyone edits the visible PDF, the edit no longer matches the sealed data, and the check below detects it.

Three independent anchors of trust

The document is designed so that verification never depends on Get Patient Consent being online, in business, or willing to cooperate. Three things make that possible:

1. A digital signature over the record, made with our private signing key. The matching public key is published at a permanent web address and kept published forever, including old keys after they are rotated. Anyone can fetch the public key once and use it to check the signature. The private key never leaves us; the public key is all a verifier needs.

2. An independent trusted timestamp. At sign-off, the signature is certified by an independent Time-Stamp Authority (a neutral third party, under RFC 3161), which returns a token attesting the time. This anchors when the consent was signed to a party with no stake in the outcome — not to our own clock — and so shows the consent existed before the procedure. The timestamp is obtained before a consent is treated as signed, so every signed record carries one.

3. A self-contained document. The sealed data, the signature and the timestamp are all embedded inside the PDF. A verifier can extract them with ordinary tools and check everything offline. Nothing has to be requested from us.

Because of this, the root of trust is: the document you hold + a published public key + standard software. Our own verification web page (described below) is only a convenience. It is never the thing that makes the document trustworthy.

Why we built it this way

A consent record may need to be relied on years or decades after it was signed, possibly in a dispute, and possibly long after any particular company or website still exists. A verification method that depended on our servers would make our continued existence part of the evidence. Independent verifiability removes us from that chain entirely. It is better for the patient, better for the clinician relying on the record, and — being checkable by anyone — stronger evidence in any forum that has to weigh it.

Part 2 — How to verify a document yourself

This section is for a technically competent reader: an engineer, an auditor, or a digital-forensics expert. It uses only widely available, open tools. No software from Get Patient Consent is involved in the check.

What is inside the document

A signed consent PDF contains these embedded files (PDF/A-3 "associated files"), extracted with pdfdetach -saveall consent.pdf:

• consent-record.json — the exact sealed record (the canonical bytes that were signed).
• consent-record.integrity.json — the detached integrity record: the digital signature (server_signature, base64), the key identifier and fingerprint, the public-key location, and the RFC 3161 trusted-timestamp token.
• HOW-TO-VERIFY.txt — a short copy of these instructions.

Tools you will need

• poppler-utils (provides pdfdetach) to extract the embedded files.
• coreutils (provides sha256sum) to fingerprint data.
• OpenSSL to check the digital signature and the timestamps.

All three are free, open-source, and available on Linux, macOS and Windows.

Step 1 — Extract the embedded files

pdfdetach -saveall consent.pdf
# produces consent-record.json, consent-record.integrity.json, HOW-TO-VERIFY.txt

Step 2 — Confirm the content fingerprint

The integrity record holds the SHA-256 of the sealed record. Recompute it and compare:

sha256sum consent-record.json
# compare the value to "canonical_sha256" in consent-record.integrity.json — they must match

If they differ, the embedded record has been altered and verification fails here.

Step 3 — Verify the digital signature

The signature is carried in the integrity record as server_signature (base64). Extract it, fetch the public key named by key_id, confirm the key is genuine by checking its fingerprint against key_fingerprint_sha256, then verify the signature over the exact bytes of consent-record.json:

# extract the detached signature
python3 -c "import json,base64; open('sig.bin','wb').write(base64.b64decode(json.load(open('consent-record.integrity.json'))['server_signature']))"

# one-time: fetch and pin the public key named in the integrity record (key_id)
KEY_ID=$(python3 -c "import json;print(json.load(open('consent-record.integrity.json'))['key_id'])")
curl -O https://raw.githubusercontent.com/Get-Patient-Consent/getpatientconsent-verify/main/keys/$KEY_ID.pem
openssl pkey -pubin -in $KEY_ID.pem -outform DER | sha256sum   # compare to key_fingerprint_sha256

# verify the signature (standard ES256 / DER ECDSA)
openssl dgst -sha256 -verify $KEY_ID.pem -signature sig.bin consent-record.json
# expected output: "Verified OK"

Verified OK means this exact record was signed by the holder of that key (Get Patient Consent) and has not changed by a single byte since.

Step 4 — Check the independent timestamp (the "when")

Each consent carries a single RFC 3161 timestamp token, taken at sign-off from an independent Time-Stamp Authority. Because a timestamp cannot live inside the data it certifies, the token is issued over the signature, not the canonical bytes, so it is verified against server_signature:

# extract the token (base64 DER) from the integrity record
python3 -c "import json,base64; open('ts.token','wb').write(base64.b64decode(json.load(open('consent-record.integrity.json'))['trusted_timestamp']['token_base64']))"

# verify the token against the signature, using the TSA's archived CA cert
openssl ts -verify -data sig.bin -in ts.token -CAfile keys/tsa/<tsa>-cacert.pem
# expected output: "Verification: OK"

# read the attested time
openssl ts -reply -in ts.token -text | grep -i "Time stamp"

The tsa field in the record names the authority that issued the token, and its CA certificate is archived under keys/tsa/ so the token verifies offline even if that authority disappears. A genuine Verification: OK here, plus the signature check in Step 3, proves the consent existed — intact — at the attested time, without contacting anyone.

Step 5 (optional) — Confirm the PDF you see matches the sealed data

Because the visible PDF is only a rendering of canonical.json, you can regenerate the view from the sealed data and confirm it agrees with what is printed on the page. Any discrepancy between the visible document and the sealed record is itself the tamper signal — the sealed record, not the visible layer, is authoritative.

What each check establishes

None of these steps contacts Get Patient Consent. A complete, conclusive verification can be performed entirely offline by anyone holding the document and the published public key and timestamp-authority certificates.

The public verification repository

Everything needed to verify independently is published in a separate, public repository:

https://github.com/Get-Patient-Consent/getpatientconsent-verify

It holds the public signing keys (current and every retired key), the timestamp-authority certificates, and a small, dependency-free verification tool (verify.mjs) you can read and run yourself. It is deliberately separate from our application so that consent records remain verifiable regardless of the company's status — the repository is public, forkable and mirrorable.

We also provide an online verifier (upload a document, or look it up by id) as a convenience, but it carries no special authority: the cryptographic proof lives in the document itself, and the authoritative way to rely on it is the independent procedure in Part 2, using the published keys.

Scope and limitations

• Verification confirms integrity, authorship and timing. It does not, on its own, establish that consent was clinically valid; that depends on the consent discussion, the patient's capacity, and the information provided.
• The published signing keys and timestamp-authority certificates are the trust anchors. We commit to keeping them published permanently, including rotated keys, so that historic documents remain verifiable indefinitely.
• If you believe a document fails verification, or you cannot reproduce a successful check, please contact us at hello@getpatientconsent.com — but note that a genuine document does not require our involvement to be verified.

Glossary

• SHA-256 — a standard cryptographic fingerprint. Any change to the input, however small, produces a completely different fingerprint.
• Digital signature — a value that proves a specific record was sealed by the holder of a particular private key, and has not changed since. Checked with the corresponding public key.
• Public / private key — a key pair. We keep the private key secret and use it to sign; the public key is published so anyone can verify.
• RFC 3161 / Time-Stamp Authority (TSA) — an internet standard and the neutral third parties that implement it, certifying that data existed at a given time.
• PDF/A-3 — an ISO standard for archival PDFs that can carry machine-readable data files embedded alongside the human-readable page — the mechanism that lets one document be both readable and independently checkable.