We build a documentation API at Twofold that returns both a clinical note and structured data, so we spend a lot of time on the gap between prose and coded fields. This article explains what structured encounter data is, how it's coded, and why it's the part that makes a healthcare product actually useful downstream.
It's easy to focus on the note — it's what clinicians read and sign. But the codes underneath are what let you bill, analyze, and exchange that visit. Treating them as an afterthought is where a lot of products get stuck.
From a note to coded fields
The hero image above shows the core idea: the same encounter exists as a readable note and as a set of coded fields. A clinician documents 'generalized anxiety disorder, continue sertraline 50 mg, recheck PHQ‑9 in four weeks.' Structured data captures that as a Problem (ICD‑10), a Medication (RxNorm), an Encounter (CPT), and an Observation (LOINC) — the same facts, in a form a system can act on.
The anatomy of structured encounter data
Each part of the encounter maps to an established clinical data standard so different systems agree on what a field means. The diagram below breaks it down.
Problems → ICD-10 and SNOMED CT
Diagnoses and problems are coded to ICD‑10 (required for billing and reporting) and often SNOMED CT (richer clinical meaning). This is what turns 'anxiety' into a specific, exchangeable concept.
Medications → RxNorm
Drugs, doses, and routes are normalized to RxNorm so 'sertraline 50 mg PO daily' means the same thing across systems — essential for medication reconciliation and interaction checking.
Procedures → CPT and HCPCS
Services and procedures map to CPT/HCPCS, the codes that drive claims. Getting these right and present is the difference between a clean claim and a denial.
Observations → LOINC
Vitals, labs, and standardized scores (like PHQ‑9) are coded to LOINC, so results are comparable and trendable rather than trapped in narrative text.
The bundle → FHIR
All of it is packaged as FHIR resources — DocumentReference, Condition, MedicationStatement, Encounter, Observation — so the encounter can be exchanged with any FHIR‑capable EHR or system without custom mapping.
Why it matters
Structured data is what makes an encounter useful beyond the chart note. Billing and coding need ICD‑10 and CPT present and correct. Analytics, quality measures, and population health need discrete fields to aggregate — you can't compute a quality metric from prose. And clean hand‑off to any EHR or downstream system depends on standardized, FHIR‑shaped resources rather than free text someone has to re‑key.
Put differently: the note proves what happened; the structured data lets the rest of your product — and the broader health system — do something with it.
Note vs. structured data — they work together
These aren't competing outputs. The note is the human‑readable, signable narrative; the structured data is the same content as coded fields. The risk is letting them drift — codes that don't match the note, or a note with no codes behind it. A documentation engine that produces both from one encounter keeps the prose and the codes consistent by construction.
How to get structured data from an encounter
There are two realistic paths. You can build the extraction layer yourself on top of a transcript: medical entity recognition, normalization to ICD‑10/RxNorm/CPT/LOINC, validation, and FHIR mapping — a real, ongoing investment. Or you can use a documentation API that returns the note and the structured data together, already coded and FHIR‑shaped.
For most teams the second path is faster and more reliable. Our medical speech-to-text and documentation API returns a finished note plus coded, FHIR‑ready structured data from one encounter — and for platforms that want the whole experience embedded and branded, our partner program offers the same engine as a white‑label product.