Resources
Straight to R4
Resolved rows are emitted as FHIR R4 resources — Patient, Observation, Claim and the rest — using each template’s fhir_resource mapping. No separate transform step to build and maintain yourself.
⇌AdaptivMapr
Capability · FHIR
Emit resolved rows as FHIR R4 resources.
Map your rows once, then emit them straight to FHIR R4 — Patient, Observation, Claim and more — via each template’s fhir_resource. A healthcare feature layered on the same engine, not a walled-off gate.
output: fhir
What you get
Built for regulated workloads
For healthcare workloads, mapping to your columns is only half the job — you often need FHIR out the other side. Templates that carry a fhir_resource can emit their resolved rows directly as FHIR R4 resources: a patient_demographics row becomes a Patient, a lab_results row becomes an Observation. The emit path is vertical-agnostic — it’s a healthcare feature layered on the same cascade, not a special-cased gate — and it’s available from both convert and the commit path.
Same engine
One cascade, FHIR at the end
FHIR emit rides the same mapping engine every other source uses. You map to the template’s fields once; asking for FHIR out is a flag on the output, not a different product.
Validated
Checked before it’s emitted
Field validators — including fhir_reference, loinc_code and icd10_code — run at commit, so the values inside an emitted resource are checked rather than assumed. Malformed codes are flagged, not shipped.
Two paths
On convert and on commit
Ask for output: fhir from /v1/convert to turn an extracted document into resources, or from the commit path to emit a mapped upload — the same FHIR output, wherever the rows came from.
Try it
A real call, end to end
Set output to fhir on a commit or a convert call for a template that carries a fhir_resource, and get R4 resources back instead of flat rows.
curl
curl https://api.adaptivmapr.com/v1/convert \
-H "Authorization: Bearer $MAPR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"target": "patient_demographics",
"output": "fhir",
"source": { "type": "pdf", "data": "data:application/pdf;base64,JVBER…" }
}'response
{
"resourceType": "Bundle",
"type": "collection",
"entry": [
{ "resource": {
"resourceType": "Patient",
"identifier": [{ "value": "A-1002" }],
"name": [{ "given": ["Ada"], "family": "Lovelace" }],
"birthDate": "1985-12-10"
} }
]
}FAQ
Common questions
No. Templates that support it carry a fhir_resource mapping, so once your rows are mapped to the template’s fields the FHIR resource is derived for you. You ask for output: fhir; the template already knows how its fields become an R4 resource.
The emit path itself is vertical-agnostic — it’s a general output mode, not a special gate. In practice it’s the healthcare templates (Patient, Observation, Claim and so on) that carry a fhir_resource, because that’s where FHIR is the target format.
Whichever the template maps to — commonly Patient, Observation and Claim across the healthcare templates. The resource is whatever that template’s fhir_resource declares.
Yes — the same commit-time validators apply, including fhir_reference, loinc_code and icd10_code. A code that fails its check is flagged before the resource is emitted, not shipped inside it.
Ready when you are
Put fhir r4 emit in production — without shipping raw records.
Spin up a key in minutes. Top up a $10 prepaid wallet — every map is a few tokens.
$10 minimum to start · pay only for what you map · PHI under BAA coverage