Extracting Data From a Birth Certificate

“The parents’ names are missing” is the most common finding from an automated birth certificate pipeline, and most of the time nothing went wrong: the certificate is a short form and never carried them. Until the schema can express that, every short form looks like a failed extraction.

Two documents wearing one name

Vital records offices in the United States and in many other jurisdictions issue at least two things from the same underlying record. The long form — variously a certified copy of the record of live birth, a photocopy of the original registration, or a full-image certificate — reproduces the registered detail: the child’s full name, date, time and place of birth, the hospital or facility, the parents’ full names including a mother’s name before marriage, sometimes the parents’ birthplaces and ages, the attendant, and the date the record was filed with the registrar.

The short form — a certification, abstract or card — reproduces a subset: typically name, date of birth, place of birth, sex and a file number, with the registrar’s certification. It is a smaller document by design and it is not a degraded copy of the long form.

The distinction has consequences beyond the extraction. The US State Department’s criteria for accepting a birth certificate as evidence of citizenship require it to show the applicant’s full name, date and place of birth, the full names of the parents, the seal or other certification of the official custodian, and the date the record was filed with the registrar — with additional evidence required where the record was filed more than a year after the birth. A short form frequently does not meet that, which is exactly why a pipeline needs to know which form it is holding rather than which fields it happened to find.

So make the variant a field the model must fill, not something you infer from absence. Detect it from the document’s own title text — certificates label themselves — and use the field to drive completeness checking. A missing parent name on a long form is a finding; on a short form it is the expected state.

The seal problem

A certified vital record carries a seal, and the seal is where the extraction actually breaks. There are three kinds and they fail differently.

• An embossed seal has no ink at all. It is a relief pressed into the paper, so on a flatbed scan under even lighting it is nearly invisible, and on a phone photograph under raking light it appears as a ring of shadow that OCR reads as noise or as a circle of spurious characters. It typically sits over printed text.
• An inked or foil seal is opaque and genuinely obscures whatever is beneath it. Characters under it are gone, not faint, and no amount of preprocessing recovers them.
• A security-paper background — the intaglio patterning, coloured guilloche and microprint used on certificate stock — lowers contrast across the whole document, which is why a birth certificate often OCRs worse than a plain photocopy of the same information.

The practical response is to expect partial occlusion of a specific region rather than to fight it. Certificates place the seal in a consistent area for a given issuing office, so the affected fields are predictable; the file number and the registrar’s signature block are the usual casualties. Record occluded characters as unknown rather than letting a model complete them, because a completed file number is the worst possible outcome: it is well-formed, it is wrong, and nothing downstream can tell.

Where the source is a photograph rather than a scan, the seal is also the one artefact that benefits from asking for a second image at a different angle. That is a workflow answer rather than a model answer, and it is usually cheaper than any preprocessing.

Three dates, one of which is not the birth

A certificate carries the date of birth, the date the birth was filed with the registrar, and the date this particular copy was issued. They are all formatted the same way and they appear near each other. A schema with one date field takes whichever the model saw first.

The filing date is the one most often confused with the birth date, and it is meaningful in its own right: a record filed long after the birth is treated differently by relying parties, which is the whole point of the one-year criterion mentioned above. The issue date belongs to the copy rather than to the person — a certificate issued last month for a birth in 1988 is entirely normal, and a system that reads the issue date as the birth date produces a newborn adult.

A time of birth appears on many long forms and is genuinely useful for disambiguating multiple births. Extract it, and expect it in several formats including a 24-hour clock, an AM/PM clock, and the occasional 12:00 M for noon on older forms. Two siblings with the same date and different times is a normal record, not a duplicate.

Assert the ordering: birth date is on or before filing date, and filing date is on or before issue date. Those two inequalities catch a transposed pair without knowing anything else about the document, in the same way the date ordering check works on a driver’s licence.

Amended and replacement certificates

A birth record can be amended, and the resulting certificate is a normal document your pipeline will see. Amendments arise from corrections to a registered detail, from a change of name, from a later determination of parentage, and from adoption — in which case many jurisdictions issue a new certificate that replaces the original entirely.

Two things follow for the schema. First, an amended marking is a field to extract, not noise to filter: it is usually a stamp or a printed annotation, and its presence changes how a relying party treats the document. Second, and more important, an amended certificate is highly sensitive: the fact that a certificate was amended can reveal adoption or a change of gender marker, and neither is something a general-purpose extraction record should carry into a system that did not need it. Extract what the process requires and nothing else, and keep the amendment flag out of any record that flows further than it has to.

The same logic applies to the whole document. A birth certificate contains identifiers — a file number, parents’ names, a hospital — that are rarely needed by the process that wanted a date of birth. Redacting the fields you do not need before the image reaches a third-party model reduces both your exposure and the volume of sensitive data in request logs; the mechanics are in PII redaction, and the contractual question about the data leaving your infrastructure at all is covered in the GDPR subprocessor checklist.

The record, and what it must not assert

{
  "document_variant": "long_form",       // long_form | short_form | unknown
  "jurisdiction": { "state": "XX", "county": "Synthetic County" },
  "registrant": {
    "given_names": "Sample", "family_name": "Person",
    "sex": "F",
    "date_of_birth": "1988-04-17",
    "time_of_birth": "03:41",
    "place_of_birth": { "facility": "Example General Hospital",
                        "city": "Synthetic City" }
  },
  "parents": [
    { "role": "parent_1", "name": "Synthetic Parent A" },
    { "role": "parent_2", "name": "Synthetic Parent B",
      "name_before_marriage": "Synthetic Maiden" }
  ],
  "registration": {
    "file_number": null,
    "file_number_status": "occluded_by_seal",
    "date_filed": "1988-04-25",
    "date_issued": "2026-02-03"
  },
  "amended": false,
  "field_expectations_met": true
}

Three deliberate choices. Parents are an array with a role rather than mother and father fields, because certificates in many jurisdictions no longer use those labels and a fixed pair cannot represent a single parent or two parents of the same sex. The file number carries a status rather than being merely null, so occlusion is distinguishable from absence. And field_expectations_met is computed from document_variant — a short form missing parent names passes, a long form missing them does not — which is what stops the review queue filling with correct extractions.

One thing the record must never carry is a judgement about whether the document is genuine. A pipeline can report that a field was unreadable, that a date ordering failed, or that a form variant does not match what was requested. Whether a certificate is authentic is determined by the issuing vital records office, and the only reliable route is verification with that office.