Extracting Structured Data From a Consent Form

A consent form that has been read correctly and never signed is not consent. The extraction that matters on this document is the boring one: is there a signature, is there a date beside it, is it the right version, and did the person initial the optional parts.

Two extractions, not one

Consent documents — research consent, procedural consent, data processing consent, photography and media releases — split cleanly into two extractions that share a page and share nothing else.

The content extraction answers what was consented to: the study or procedure identified, the purposes listed, the duration, the parties who may receive data, the withdrawal terms. It is prose extraction against a mostly fixed template, and it is the same document for every person who signs it, which means it needs doing once per version rather than once per scan. That observation alone removes most of the cost from a consent-processing pipeline: recognise which template version this is, look up the content you already extracted, and only process the parts that differ per person.

The execution extraction answers whether this particular copy was validly completed. It is per document, it is the part that varies, and it is almost entirely about presence and position rather than about text.

Building both as one prompt is how pipelines end up expensive and weak — the model spends its attention on template boilerplate it has seen a thousand times and gets the signature question, which is the only question, as an afterthought.

The execution gate

The requirements differ by jurisdiction and context, and this page is not the place to learn which apply to you. What is worth naming is that they exist and that they are specific: in US regulated clinical research, for example, the FDA’s informed consent regulation at 21 CFR 50.27 requires that informed consent be documented by a written consent form signed and dated by the subject or the subject’s legally authorised representative at the time of consent, with a copy given to the person signing. Signed and dated, by a specified person, at a specified time. Every clause there is a field.

The gate that follows is a small set of independent checks:

• Signature present in the subject signature region.
• Date present beside it, and parseable.
• Date plausible — not in the future, not before the document version’s own approval date, and within any window your process requires relative to the procedure or enrolment date.
• Signatory role identified — subject, legally authorised representative, parent or guardian, witness, person obtaining consent. A form signed only by the person obtaining consent fails, and this is a real and common defect.
• All required signature blocks filled. Forms often carry three or four blocks and only some are required for a given situation, which makes this a rule keyed on the form version rather than a blanket check.

Report each independently. A single “valid” boolean tells the person clearing the queue nothing about what to fix, whereas “signature present, date absent” tells them exactly which person to call.

Detecting a signature is not OCR

Asking a model to transcribe a signature produces a name, confidently, and the name is frequently wrong because signatures are not written to be read. Worse, it produces a name when the region is empty, because a form with a printed name elsewhere on the page supplies an obvious candidate.

The question to ask instead is whether ink is present in a defined region, which is a different task with a different failure profile. In practice that means locating the signature line — a horizontal rule with a printed label beneath or beside it — and evaluating the area above the rule for marks. Two distinctions matter and are worth asking for explicitly:

• Printed name versus signature. Many forms have both, adjacent, and a block-capital printed name in the signature box is a defect on some processes and acceptable on others. Report which one you found rather than collapsing both to “signed”.
• Wet ink versus an electronic signature block. An e-signature platform stamps a typeset name, a timestamp and often a certificate identifier into the region. That is a valid signature in many contexts and it is not ink; a detector tuned for strokes reports the form as unsigned. Detect the stamp pattern separately and record the signature type as a field.

Signature detection is also where a per-field confidence number earns its place, because the answer is genuinely uncertain on faint scans and the cost of both error directions is high. Route the uncertain band to a person rather than thresholding it into a boolean; how much of the confident band you also sample is a separate decision and worth making deliberately.

Optional elements and their initials

Consent is not one decision. Research consent forms routinely present optional sub-consents, each with its own initials box: permission to retain biological samples for future research, permission to be contacted about future studies, permission to share data with named third parties, permission for photography. These are independent choices and each has its own state.

Three states, again, and the third is the one that gets lost. Initialled yes, initialled no where the form offers both boxes, and left blank. A blank optional element is not a no in every process — some treat it as a defect requiring the form to be re-executed — and a pipeline that defaults blanks to false has made a decision that was not its to make. Extract { option_id, state: "yes" | "no" | "blank", initials_present: bool } and let the process that owns the policy decide.

The same applies to any strike-through. A person who crosses out a clause and initials the deletion has consented to something different from what the template says, and that is a material fact about this copy. Detecting struck text is region-level work rather than transcription, and a struck clause silently transcribed as live is a worse outcome than an unparsed form.

Version and validity

Consent forms carry a version identifier and often an approval stamp in the footer — a version number, a version date, and in research contexts an ethics or institutional review board approval date and sometimes an expiry. That footer is small, repeated on every page, and the field most often skipped, and it is what makes the document interpretable.

Two checks fall straight out of it. A signature dated before the version’s approval date, or after its expiry, means the person signed a document that was not the approved one at that moment. And a version identifier that does not match the version your process expected for that person means the content extraction you looked up is the wrong content. Both are cheap to compute and neither is possible if the footer was never extracted.

Finally, on handling. These documents identify a person by name and signature and frequently carry a date of birth or an identifier alongside. Everything about minimising what leaves your infrastructure applies — send the region you need rather than the page where you can, redact identifiers you are not extracting, and hold the vendor relationship to terms appropriate to the data. This page is about getting fields out of a document your organisation already holds lawfully; whether you may hold it, and for how long, is a question for the people who own that decision.