Skip to main content
FHIR R4 defines more than a hundred resource types. Scan maps a named subset to FHIR R4 4.0.1 (the US Core / CMS target). This page defines the current crosswalk so a health-plan or EHR architect can estimate adapter work; resources not listed here are not supported. Scan is not a FHIR server. Do not put “FHIR-compatible” on a procurement checklist from this page alone. visits[].status remains the operational source of truth. FHIR statuses below are a lossy collapse onto required value sets.

Resource crosswalk

Appointment.status

DiagnosticReport.status

Do not treat report_uploaded as clinically final. Un-QC’d radiology must not surface to a clinician. Reports can still be outstanding on multi-procedure referrals.

Read endpoints

When fhir_read is enabled for the account:
  • GET /api/v2/fhir/diagnostic_reports/{order_id}
  • GET /api/v2/fhir/imaging_studies/{order_id}
Lookup is order id or ?accession=. There is no FHIR search grammar.

Not supported

No /metadata CapabilityStatement, no FHIR search, no $everything, no Subscriptions, no SMART on FHIR or OAuth scopes, no bulk export, no POST Bundle, no FHIR writes. Outbound events are Scan-native webhooks, not FHIR Subscriptions. gender on Patient is administrative sex (male / female / other), not USCDI v3 gender identity. Body part and laterality are display strings, not SNOMED codes. They are useful for display, but software cannot safely treat them as standardized clinical codes without a partner-maintained mapping or human review.