> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corti.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Reduce extraction errors

> Learn three habits that keep FHIR Extraction errors out of your data: send what you already know, skip data you already have in structured form, and review results before they reach the record

FHIR Extraction uses a language model to read the note. Like any reader, it can misread. Three habits keep those errors out of your data:

1. [Send what you already know](#send-what-you-already-know) about the patient and the encounter.
2. [Skip data you already have in structured form](#skip-data-you-already-have-in-structured-form), such as lab results from your lab system.
3. [Review the results](#review-the-results-before-they-reach-the-record) before they reach the patient record.

## Send what you already know

Your EHR or scheduling system already holds the patient's ID, date of birth, and gender, and the visit's ID, setting, and dates. A note only mentions some of these, and sometimes in a way that is easy to misread. When you send a value in `patient` or `encounter`, the endpoint uses your value and ignores what it reads in the note. Each field you send is one less field the model has to read, and one less chance to get it wrong.

Here are mistakes you avoid that way:

| Note says | Extracted from the note alone | What goes wrong | Send instead |
| - | - | - | - |
| "58-year-old woman" | No `birthDate` | The endpoint does not calculate a date of birth from an age, so the age is lost. | `"birthDate": "1968-04-02"` |
| "Admitted 03/04/2026" | `period.start` of `2026-03-04` | The date could be 3 April or 4 March, depending on the country that wrote it. | `"period": { "start": "2026-04-03" }` |
| "Seen with her husband, John Miller" | `name` might pick up the wrong person | A note names relatives and clinicians, not only the patient. | `"name": "Anna Miller"` |
| "Discharge summary" with no status word | `status` of `in-progress`, the default | The endpoint does not guess status from the type of note, so a finished stay can look ongoing. | `"status": "finished"` |
| "Follow-up, see above" | `class` marked unknown | The note never says "outpatient", so the endpoint marks the setting as unknown instead of guessing it. | `"class": "ambulatory"` |
| "Admitted 3 April 2026 at 14:20" | `period.start` of `2026-04-03` | The note states no timezone, and R4 accepts a time only with one, so the time of day is dropped. | `"period": { "start": "2026-04-03T14:20:00+02:00" }` |
| Any note | A generated `identifier` | The generated ID means nothing to your EHR, so you cannot match the resources to your records. | `"identifier": "<your-patient-id>"` |

Send every value you have, even when the note also states it. The `patient` object has 4 fields and the `encounter` object has 8. A request with every field looks like this:

```json theme={null}
{
  "context": { "context_type": "other", "data": "Discharge summary. 58-year-old woman admitted 03/04/2026 with community-acquired pneumonia." },
  "patient": {
    "identifier": "<your-patient-id>",
    "name": "Anna Miller",
    "gender": "female",
    "birthDate": "1968-04-02"
  },
  "encounter": {
    "identifier": "<your-encounter-id>",
    "status": "finished",
    "class": "inpatient",
    "priority": "urgent",
    "type": "Emergency admission",
    "serviceType": "Internal medicine",
    "reasonCode": "Community-acquired pneumonia",
    "period": { "start": "2026-04-03T14:20:00+02:00", "end": "2026-04-08T10:00:00+02:00" }
  }
}
```

Where the values come from in a typical EHR:

| Field | Typical source |
| - | - |
| `patient.identifier`, `name`, `gender`, `birthDate` | The patient's demographics record |
| `encounter.identifier`, `status`, `class` | The visit or admission record |
| `encounter.period` | Admission and discharge times, or the appointment slot |
| `encounter.priority`, `type` | The admission type or appointment type |
| `encounter.serviceType` | The department or specialty that owns the visit |
| `encounter.reasonCode` | The referral reason or chief complaint at registration |

[Request and response](https://docs.corti.ai/fhir/request-and-response.md#patient) lists the allowed values for each field. [Patient & Encounter](https://docs.corti.ai/fhir/resource-groups/patient-and-encounter.md#example) shows the resources this request returns.

## Skip data you already have in structured form

Many clinical systems already hold part of the record as structured data, straight from the source. Use that source, and turn off the matching resource groups and categories with [`resourceGroups`](https://docs.corti.ai/fhir/filtering#choose-which-resources-to-produce):

| You already have | From | Turn off |
| - | - | - |
| Lab results | Your laboratory information system, for example as HL7 v2 or FHIR messages | Observation category `laboratory` |
| Vital signs | Monitors, or flowsheets in your EHR | Observation category `vital-signs` |
| Allergy list | Your EHR's allergy module | `AllergyIntolerance` |
| Imaging results | Your radiology information system | Observation category `imaging` |

The structured source is the truth. A note only repeats it, and extracting the value again can only make it worse:

* **The model can misread.** Every extracted value carries a small risk of error that the structured source does not have.
* **The note may be wrong already.** A clinician types "HbA1c 7.2" when the lab reported 7.4, or copies last month's "K 3.1" forward when today's potassium is normal.
* **The note leaves out details.** A lab result in a note rarely carries its unit, reference range, specimen, collection time, or the exact test the lab ran. A blood pressure in a note rarely says when, where on the body, or with which device.

If you want to keep an extracted group that overlaps your structured data, such as allergies, use the extracted resources only to suggest additions for a clinician to review.

The "Skip lab results and vital signs" example in [Choose which resources to produce](https://docs.corti.ai/fhir/filtering.md#choose-which-resources-to-produce) shows the request.

## Review the results before they reach the record

Wherever you can, show the extracted resources to a clinician before they reach the patient record. Review matters most when the result changes care, such as a new problem-list entry or a new allergy. The response gives a reviewer what they need:

* **[Mentions](https://docs.corti.ai/fhir/how-it-works.md#mentions)** point to the words in the note behind each field. Highlight them next to the value, so the reviewer can check it at a glance.
* **[Alternatives](https://docs.corti.ai/fhir/how-it-works.md#alternatives)** list other codes that could fit. Offer them as one-click corrections.
* **Status and value fields** need the closest look, because they change the meaning of a code. A Condition with `verificationStatus: refuted` means the patient does **not** have it. See [Codes are positive](https://docs.corti.ai/fhir/how-it-works.md#codes-are-positive).

## Next steps

> [card] [Filter FHIR resources](https://docs.corti.ai/fhir/filtering.md)
>
> Turn off the resource groups and categories you already have.

> [card] [How FHIR Extraction works](https://docs.corti.ai/fhir/how-it-works.md)
>
> Learn how mentions, alternatives, and status fields work.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.