FHIR Destination

The FHIR destination is purpose-built for sending resources to a FHIR server, with native support for create, update, and transaction bundle operations. It understands FHIR semantics — resource types, bundle entries, and server responses — so you get structured error handling and validation that a generic HTTP POST cannot provide.

If your target is a FHIR-conformant server, prefer this destination over the HTTP destination for richer integration behavior.

Configuration

destination:
  type: fhir
  fhir:
    base_url: https://fhir.hospital.org/r4
    version: R4
    operations:
      - create
      - update
    validate_resources: true
    auth:
      type: oauth2
      token_url: https://idp.hospital.org/oauth2/token
      client_id: ${FHIR_CLIENT_ID}
      client_secret: ${FHIR_CLIENT_SECRET}
      scope: system/*.write
    tls:
      ca_file: ./certs/hospital-ca.crt
    timeout_ms: 30000

Properties

Property	Type	Required	Default	Description
`base_url`	`string`	Yes	—	FHIR server base URL (e.g., `https://fhir.hospital.org/r4`).
`version`	`string`	No	`R4`	FHIR version: `R4` or `STU3`.
`operations`	`string[]`	No	`["create"]`	Allowed FHIR operations: `create`, `update`, `transaction`.
`validate_resources`	`bool`	No	`false`	Validate outbound resources against the FHIR schema before sending.
`auth`	`object`	No	—	Authentication configuration (supports `basic`, `bearer`, and `oauth2`).
`tls`	`object`	No	—	TLS settings for the connection.
`timeout_ms`	`int`	No	`30000`	Request timeout in milliseconds.

Authentication

The FHIR destination supports the same authentication strategies as the HTTP destination:

Basic

auth:
  type: basic
  username: ${FHIR_USER}
  password: ${FHIR_PASSWORD}

Bearer Token

auth:
  type: bearer
  token: ${FHIR_TOKEN}

OAuth 2.0 (Client Credentials)

auth:
  type: oauth2
  token_url: https://idp.hospital.org/oauth2/token
  client_id: ${FHIR_CLIENT_ID}
  client_secret: ${FHIR_CLIENT_SECRET}
  scope: system/*.write

FHIR vs HTTP Destination

Capability	FHIR Destination	HTTP Destination
FHIR-aware operation routing	Yes	No
Transaction bundle support	Yes	Manual
Resource validation	Built-in	Manual
Structured FHIR error parsing	Yes	Generic HTTP status
Simple POST to a URL	Use HTTP instead	Yes

Use the FHIR destination when the target is a FHIR server and you benefit from operation semantics, bundle support, or resource validation. Use the HTTP destination when you just need a simple POST to a FHIR-like endpoint without those features.

Complete Example

Send FHIR Patient and Encounter resources as a transaction bundle with OAuth 2.0 authentication:

id: adt-to-fhir
enabled: true
group: admissions

source:
  type: tcp
  port: 6661
  content_type: hl7v2
  mllp: true

transformer: adt-to-fhir-bundle.ts

destinations:
  - type: fhir
    fhir:
      base_url: https://fhir.hospital.org/r4
      version: R4
      operations:
        - transaction
      validate_resources: true
      auth:
        type: oauth2
        token_url: https://idp.hospital.org/oauth2/token
        client_id: ${FHIR_CLIENT_ID}
        client_secret: ${FHIR_CLIENT_SECRET}
        scope: system/Patient.write system/Encounter.write
      tls:
        ca_file: ./certs/hospital-ca.crt
      timeout_ms: 30000