Mapping extracted fields to an EHR takes four decisions: which integration path writes the data, which EHR field each extracted value lands in, how the document is matched to the right patient, and which values a person must confirm first. Write those decisions into one mapping table before any value reaches a chart.
EHR integration options for document data
An EHR integration option is the route by which values pulled from a document get into the electronic health record. There are five common routes: a FHIR API, an HL7 version 2 interface, a vendor's own API, a flat-file import and a plain attachment of the scanned page. Most organizations end up using two or three of them.
FHIR APIs
FHIR is HL7's standard for exchanging health data as resources over a REST interface. The resources most document data maps to are the FHIR R4 Patient resource for demographics, the FHIR R4 Observation resource for lab results, and the FHIR R4 DocumentReference resource for the source page itself. The DocumentReference page names scanned paper and digital records of faxes among the documents it can index. FHIR suits teams that need to write one value at a time and read back what the chart already holds.
HL7 version 2 interfaces
HL7 version 2 is the older messaging standard. The FHIR R4 comparison with HL7 v2 describes it as one of HL7's most widely adopted standards, built from reusable segments, with local extensions called Z-segments whose meaning is opaque without prior explanation. An interface engine usually sits between the sender and the EHR. Which of the two standards to pick for a new feed is covered in the comparison of HL7 v2 messages and FHIR resources side by side.
Vendor APIs, flat files and attachments
Some EHRs expose their own API alongside or instead of FHIR, with fields and rules described only in that vendor's documentation. Flat-file imports load a spreadsheet or delimited file on a schedule, which works for batches of demographic updates but rarely for clinical values. The simplest option attaches the scanned page to the chart with a few index fields and leaves the values for staff to read. Every other option should still keep that attachment, so a reader can see the page a value came from.
Building an EHR field mapping table
An EHR field mapping table lists each extracted field, the EHR field it writes to, the transform applied on the way, the confidence a value must reach to skip review, and the person who owns the rule. It is the single document that integration developers, clinical staff and compliance reviewers can all read and sign off.
Start from the documents, not the EHR. List every field your extraction returns for each document type, then find the target for each one. Fields with no target are either dropped on purpose or attached as text. Writing that choice down prevents a later developer from inventing a home for them.
The example below covers a fictional intake form and a fictional lab report for an invented patient, Ada Example. Every value, threshold and target name is made up for the example, and the FHIR paths are one possible target, not a requirement.
| Source field | Example value | EHR target (FHIR R4) | Transform | Confidence gate | Owner |
|---|---|---|---|---|---|
| Intake: patient name | ADA EXAMPLE | Patient.name (match only) | Split into family and given, title case | Match key, never written | Front desk lead |
| Intake: date of birth | 01/02/1980 | Patient.birthDate (match only) | Convert to YYYY-MM-DD | Match key, never written | Front desk lead |
| Intake: home phone | (000) 000-0000 | Patient.telecom | Digits only, type home | 0.95 | Front desk lead |
| Intake: insurance member ID | ZZX000000001 | Coverage.subscriberId | Uppercase, strip spaces | 0.98 | Billing lead |
| Intake: allergies list | Example allergy text | No direct write; attach as text | None | Always reviewed | Clinical lead |
| Lab: test name | Glucose | Observation.code | Look up code from the lab's test catalog | 0.95 | Lab coordinator |
| Lab: result value | 92 | Observation.valueQuantity.value | Parse number | 0.98 | Lab coordinator |
| Lab: units | mg/dL | Observation.valueQuantity.unit | Map to your unit list | 0.98 | Lab coordinator |
| Lab: reference range | 70-99 | Observation.referenceRange | Split into low and high | 0.95 | Lab coordinator |
| Lab: report status | Final | Observation.status | Map to final or preliminary | 0.98 | Lab coordinator |
| Lab: collection date | 03/04/2026 | Observation.effectiveDateTime | Convert to ISO date | 0.95 | Lab coordinator |
The FHIR data types page sets the date format as YYYY, YYYY-MM or YYYY-MM-DD, which is why the date transforms matter. The Observation page lists registered, preliminary, final and amended as status values, so a "Final" printed on a report needs an explicit mapping, not a copy of the text. The same page gives LOINC as an example binding for Observation.code, not a requirement, so your EHR's own catalog decides the code. For units, the data types page says a coded unit should be a UCUM code when the unit can be coded that way, so "mg/dL" as printed may need a lookup. The member ID row targets the FHIR R4 Coverage resource, which defines subscriberId as the insurer-assigned ID for the subscriber and links the coverage to the patient as its beneficiary.
The pre-write checklist
Before any value in the table is written, the integration should confirm each of these:
- The document is matched to exactly one patient record.
- Every field in the write meets its confidence gate, or a person approved it.
- The target field is empty, or the rule for that field allows an update.
- The transform produced a valid value for the target type.
- The source page is attached and linked to the written values.
- The write is recorded with who or what made it and when.
Front desk detail for intake data, such as consent checkboxes and scanned cards, belongs to the guide on getting intake form data into the EHR. Lab-specific handling is in the guide to entering outside lab results into an EHR.
How do I match an extracted document to the right EHR patient?
Match an extracted document to an EHR patient with at least two independent identifiers, such as name plus date of birth plus member ID, and treat anything short of a single confident match as a task for a person. A wrong match writes one patient's data into another patient's chart, which is worse than writing nothing.
Identifiers on paperwork vary in strength. A medical record number printed by your own organization is the strongest, because your system assigned it. A member ID identifies a subscriber, and family members may share it with a suffix. Names are weak on their own: they get abbreviated, misspelled and reordered. A date of birth narrows the field but repeats across a large patient base.
FHIR defines a formal matching call for this job. The FHIR R4 Patient $match operation takes a possibly incomplete Patient record and returns candidates, each with a score from 0 to 1 where 1 is the most certain match. Each result can also carry a grade from the FHIR R4 match grade value set: certain, probable, possible or certainly-not. That value set says a possible match should get additional review, for example by a human, before it is used. A sensible rule is to write automatically only on a single certain match and to send every other outcome to a queue.
When there is no match at all, do not create a new patient record from the document. A new record from a scanned page is how duplicate charts start. Route the document to registration staff, who can search with more context or register the patient properly. The guide to matching faxes to patient charts covers the manual side of that search.
What should never be written to an EHR automatically?
Low-confidence values and any field whose meaning depends on clinical judgment should never be written to an EHR automatically. A confidence score is the extraction system's estimate of how likely a value is to be correct. Below your threshold, a value belongs in a review queue, where a person checks it against the page.
Some fields need a person even at high confidence. Allergies, medication lists and problem lists change care decisions, and a correctly read word can still belong in the wrong place, such as a medication a patient stopped taking. Free-text history from an intake form is another case. Attach it to the chart as text and let a clinician decide what becomes structured data.
Demographic changes deserve their own rule. A new address or phone number on an intake form may be correct and newer than the chart, or a typo, or a relative's details. A safe default is to propose the change to registration staff instead of writing it.
Schema Care follows this pattern on its own side: fields under the threshold you set wait in a review queue, and a reviewer approves or corrects each one with the field highlighted on the page. Schema Care offers no API, SDK, webhooks, FHIR output, 835 or 837 output. EHR and billing-system integrations are a feature of its Health system plan, listed in the current Schema Care plans, and the plan names no specific EHR.
EHR mapping mistakes: overwriting chart data and duplicate records
The two mapping mistakes that do the most damage to a chart are overwriting good data with worse data and creating a second record for a patient who already has one. Both come from writes that skip a check, and both are expensive to undo after other systems have copied the bad state.
Overwrites usually come from a full update where a partial one was meant. The FHIR R4 RESTful API page notes that an update generally replaces the whole content of the resource and offers patch as the alternative for partial changes. A mapping that sends a Patient resource with only a new phone number, using a full update, can blank out every field it left out. The same page describes version-aware updates: the client sends an If-Match header with the version it read, and the server returns 412 Precondition Failed if someone changed the record in between.
Duplicates come from creates without a search. FHIR's conditional create lets a client send search criteria in an If-None-Exist header; the RESTful API page says the server ignores the create if one record matches and returns 412 if several do. Use it, or an equivalent check in your interface, for every create. When duplicates do appear, the FHIR R4 link type code system shows how records point at each other: replaced-by marks a record that must no longer be used, and seealso links two equally valid records about the same person.
Three smaller mistakes recur. Mapping a lab result without its units, so a value lands with no meaning. Dropping the report status, so a preliminary result looks final. Writing values without a link to the source page, so nobody can check them later.
Test every rule in the table on fictional documents before real ones; the guide to testing with synthetic medical documents shows how to build that set. If the EHR offers no write access at all, the trade-offs of screen automation are in the comparison of EHR integration and RPA for data entry.