Extracting Terms From a Living Will or Advance Directive

An advance directive is mostly checkboxes, and checkboxes are where extraction quietly invents things. The failure is not a misread word. It is a form where a person marked three of eight options and left five unmarked, and a pipeline that reports those five as absent data rather than as choices not made.

First, work out which instrument this is

Several different documents arrive under the same heading and they do not carry the same authority. A living will is a statement of the person’s own treatment preferences. A health care proxy or durable power of attorney for health care appoints somebody to decide. Many state forms combine both in one packet with separate parts. A POLST or MOLST form is a different thing again: a portable medical order signed by a clinician, usually one brightly coloured page, representing a clinical order rather than a declaration by the patient.

These have to be separate document types in your schema, because the fields do not correspond and because merging them produces a record that attributes a clinician’s order to the patient or the reverse. Classify first, on the form title and on the presence of a clinician signature block, and route to the right schema. A single “advance directive” schema with every possible field nullable is how the two get merged.

Within a combined packet, extract part boundaries explicitly. The agent named in the proxy part and the preferences stated in the living will part are different assertions by the same person, and later questions are almost always about one part or the other.

A checkbox has three states

The treatment preference sections on these forms are option lists: cardiopulmonary resuscitation, mechanical ventilation, artificially administered nutrition and hydration, dialysis, antibiotics, comfort or palliative care — often crossed with a condition such as a terminal condition or permanent unconsciousness. Each option is either marked or not, and the model of that has to be three-valued:

• stated — a mark is present, with the marked option recorded and the mark type noted.
• unstated — the option is printed on this form and no mark is present. The person did not express a preference on it.
• not_on_form — this form does not contain the option at all.

The rule that follows is the one this page exists for: an unmarked option must never be defaulted, in either direction. Not to “declined”, not to “wishes treatment”, not to the majority answer in your data. A blank on this form is a person who did not say, and the record has to be able to say that. Where a downstream consumer needs a decision, the correct behaviour is to surface the unstated status to a human, not to resolve it.

{
  "preferences": [
    { "intervention": "cpr",
      "condition": "terminal_condition",
      "status": "stated", "choice": "do_not_provide",
      "mark": "x", "page": 2, "quote": "I do not want cardiopulmonary resuscitation" },
    { "intervention": "dialysis",
      "condition": "terminal_condition",
      "status": "unstated", "choice": null, "page": 2 },
    { "intervention": "antibiotics",
      "condition": null,
      "status": "not_on_form" }
  ]
}

Detecting the mark itself is a vision problem rather than a language one, and it is harder than it sounds on faxed and photocopied forms: box borders thicken into what looks like a fill, a pre-printed shadow reads as a tick, and a mark that overhangs the box sits ambiguously between two adjacent options. Per-option confidence, and a threshold that sends ambiguous marks to review rather than resolving them, belongs here more than on almost any other document — the general treatment is in per-field confidence scoring and threshold-based review routing.

Conflicts, write-ins and qualifications

Real forms contain contradictions, and a schema that cannot represent one will hide it. Two mutually exclusive options both marked is common: a person marks “I direct that all life-sustaining treatment be withheld” and also marks an option in the block below that requests a specific intervention. That is not an extraction error to be resolved by picking the more likely one. It is a property of the document, and the record should carry both marks plus a conflict flag.

Write-in lines are the other case. Most forms leave space for the person to add their own words, and those words routinely qualify a marked box — “except for pain relief”, “only if two physicians agree”, “for no longer than two weeks”. Handwritten free text attached to a structured option is the hardest content on the form and the most consequential, so it is extracted verbatim, attached to the option it qualifies, and never summarised. If handwriting recognition confidence is low, the record should say so and hold the cropped image region rather than a guess — the illegible field case. The general problem is covered in handwriting recognition.

Initials beside individual options are a third convention. Some forms require the person to initial each choice, which turns a mark-present test into a match against the signature block initials. Extract the initials as text; do not attempt to verify them against a signature, which is authentication and a different discipline entirely.

Which directive is the current one

People execute more than one of these over a lifetime, and the later one usually revokes the earlier. So the extracted record is close to useless without the execution date, and the execution date is often handwritten beside the signature rather than printed.

Extract the signature date, the witness signatures and dates, and the notarial acknowledgment if present, as first-class fields with their own confidence. Some state forms require two witnesses, some require notarisation, some accept either; the document either shows those elements or it does not, and reporting what is present is the whole job. Whether what is present satisfies a particular state’s requirements is a determination for the organisation holding the form, and the extraction should present the evidence for that decision rather than making it.

Handling obligations that actually attach

An advance directive held by a provider is health information about an identified person, so the ordinary rules apply rather than any special ones: send the minimum necessary to whatever processes it, redact identifiers that the extraction does not need before the page leaves your infrastructure, and make sure the arrangement with any external model provider covers the data — a business associate agreement where United States health privacy rules apply, a data processing agreement under the GDPR, and a retention setting that does not leave scans sitting in a vendor’s logs. The general treatment of identifiers in prompts and logs is in PII redaction and PII in LLM logs.

One practical note that follows from the redaction requirement: you cannot redact the checkbox regions, which means the pages that carry the preferences are the pages that must go to the model in full. Crop rather than blanket-redact, send the option blocks and the write-in lines, and keep the demographic header out of the request entirely where your document identifier is enough to reattach the record afterwards.