Connection Information¶

Type¶

The type drop-down list contains a list of supported web service connection types (see Supported Web-Service Connection Types for more information). Changing the type resets the connection-information fields to that type's defaults and shows or hides the type-specific fields described below.

Endpoint URL¶

The fully-qualified URL of the remote service. By default the Endpoint URL is built from the Host, Port, and Location fields (see the per-type sections below). Select Manually set the endpoint URL to override or reset that auto-populated value and enter the URL directly.

For example, Host = api.example.com, Port = 443, Location = /v1/patients produces the Endpoint URL https://api.example.com:443/v1/patients.

Manually set the endpoint URL¶

When checked, the Endpoint URL field becomes editable and the Host, Port, Location, and Use HTTPS fields become read-only. Use this to set a URL that does not match the simple host/port/location pattern.

Cached Conn.¶

Sets the maximum number of HTTP client connections to keep open in a pool for this connection. The default of zero (0) disables connection caching. Every call opens a new connection and repeats the TLS handshake. A non-zero value keeps connections open between calls, which is much faster but holds resources on both sides.

The pool is scoped to the host:port pair. If every connection in the pool is in use when a new call is made, the call waits until one is returned. Size the pool to the maximum concurrency you expect to drive at the endpoint.

Allow concurrent calls to this web service¶

When checked, QIE may issue multiple concurrent HTTP calls on this connection. When unchecked, calls are serialized, which is useful for endpoints that cannot tolerate parallel requests from the same client. This checkbox is only available when the Trust Policy is something other than Use JVM Keystore/Truststore and is not available for the deprecated QIE Web Service type.

Enable cookies for this web service¶

When checked, QIE persists HTTP cookies returned by the endpoint and includes them on subsequent calls. A Clear Cookies button appears next to the checkbox to discard any cookies currently stored for this connection.

Static HTTP Headers¶

Opens a dialog for managing HTTP headers that are sent with every outbound call on this connection. Use this for headers that do not change per-message (an API version header, a tenant identifier, etc.). The button label shows the current count of configured headers.

Header values are stored and sent as literal strings. System variables, message values, and other QIE placeholders are not substituted at call time. To send a header whose value changes per message, set the header from a mapping script instead.

Common static headers

Header name	Example value	Why you might set it
`Accept`	`application/fhir+json`	Tell the endpoint which response format to return (FHIR, JSON, XML, etc.).
`Accept-Language`	`en-US`	Force responses (error messages, value-set displays, etc.) in a specific language.
`Prefer`	`return=minimal`	FHIR servers. Control whether the server echoes the full resource back on writes (`return=minimal`, `return=representation`) or how strictly it validates input (`handling=strict`).
`X-API-Key`	the secret token	API-key endpoints whose key goes in a custom header rather than in the `Authorization` header.
`X-Tenant-Id`	the tenant identifier	Multi-tenant SaaS APIs that route by tenant header.
`From`	`integration@your-org.example`	Public registries and FHIR endpoints that ask callers to identify a contact email per their terms of use.
`Cache-Control`	`no-cache`	Bypass HTTP caches between QIE and the endpoint when you must always see fresh data.
`User-Agent`	`QIE/<version>`	Endpoints that reject calls with no User-Agent or that log per-client identifiers.

FHIR endpoints

For FHIR-specific connection patterns (URL anatomy, search query syntax, Bundle types, HL7 v2-to-FHIR field mappings), see Resources -> FHIR. The FHIR Quickstart walks through building a Web Service Connection to a public FHIR sandbox end-to-end.

Headers QIE manages for you

Do not add these as static headers:

Authorization is built automatically from the Authentication Protocol section below. Adding it here either collides with the value QIE generates or is silently replaced.
Content-Type is set on each individual call based on the message being sent (JSON, XML, form-encoded, etc.).
Content-Length is set automatically by the underlying HTTP client based on the size of the request body.

Listing any of these here usually causes hard-to-diagnose problems.

Per-type fields¶

The remaining fields in the Connection Information section depend on the selected Type.

DICOMwebREST (URL Encoded / Content Encoded)SOAPIHE Web Service ProfilesGoogle Cloud Healthcare APIOpen AI APIQIE Web Service (Deprecated)

Endpoint URL¶

The base URL of the DICOMweb service, the server's DICOMweb root, for example https://pacs.example.org/dicomweb/. The Host, Port, and Location fields are not shown for this type; type the full URL directly. The endpoint path for each selected operation is appended to this URL at send time.

Operations¶

A tree of the DICOMweb services QIE supports, grouped by service: QIDO-RS (query), WADO-RS (retrieve), STOW-RS (store), and UPS-RS (Unified Procedure Step / worklist). Expand a group and check the operations the connection should expose; only the selected operations are available to mapping functions and destination nodes that use this connection. Selecting an operation sets its HTTP method, request body shape, and required headers, including the Accept header that selects the response representation, which is pre-populated from the operation definition and can be edited when a server needs a non-default representation.

Note

Per the DICOMweb standard (PS3.18), QIE places non-header parameters in the URL query string for every DICOMweb operation, regardless of HTTP method.

Response streaming¶

Web Service mapping functions that use a DICOMweb connection support response streaming to a file, which is useful for large WADO-RS retrievals of studies, series, or rendered images. See Stream to File.

Host, Port and Location¶

The host, port and location fields are used to pre-populate or build the Endpoint URL. Defaults are port = 80 and an empty location.

Use HTTPS¶

When checked, QIE switches the auto-built Endpoint URL from http:// to https://. The TLS settings in the SSL section then apply to outbound calls.

Response streaming¶

Web Service mapping functions that use a REST (URL Encoded) or REST (Content Encoded) connection expose a Stream: field. When set, the response body is streamed to the specified file path instead of being buffered in JVM memory, which is useful for large binary payloads. See Stream to File in the mapping-nodes reference for path templating rules, directory pre-creation requirements, cleanup responsibilities, and concurrency guidance.

WSDL URL¶

The URL from which QIE downloads the service's WSDL document. Changing this value (or clicking Download WSDL in the WSDL editor's toolbar) re-downloads the WSDL and replaces the cached copy.

WSDL will not download but works in a browser

If QIE rejects a WSDL URL with Invalid Endpoint URL or Error downloading WSDL even though the same URL loads in a web browser, try in order:

Drop the ?wsdl query parameter and point QIE at the bare endpoint URL. Some servers expose the WSDL at the endpoint itself when no extra parameter is passed.
Configure HTTP proxy settings under System Configuration -> Http/Https Proxy Settings and restart QIE. Browsers pick up the system proxy automatically, but QIE only uses a proxy after it is configured in QIE and the server has restarted.

InvalidDefinitionException on save

If saving the connection fails with InvalidDefinitionException, the WSDL almost certainly contains a wsdl:import that points at an unreachable URL. Check qie.log for WsdlLoader errors. The log line identifies the import that could not be resolved. Remove (or fix) the offending <wsdl:import location="..."/> line in the WSDL field below and save again.

WSDL¶

Displays the downloaded WSDL as XML. QIE parses this document to determine the available operations, parameters, and return types. The WSDL is editable for advanced cases but is normally left as downloaded. The toolbar's Download WSDL button re-fetches the WSDL from the URL above.

The Endpoint URL, Host, Port, Location, and Use HTTPS fields are not used for SOAP. The service endpoint is taken from the WSDL.

Endpoint URL¶

The base URL of the IHE actor. The host, port, and location fields are not shown for this type. Type the full URL directly. The Manually set the endpoint URL checkbox is enabled by default for this type.

Operations¶

A grid listing every IHE transaction QIE supports (XDS.a and XDS.b, both the actor-initiated and recipient-initiated transactions). Check the box next to each transaction the connection should handle. Only the selected transactions are available to mapping functions and destination nodes that use this connection.

Submitting a CDA via ITI-41

For an end-to-end walkthrough of submitting a CDA document to an HIE, including the metadata fields, MTOM, and the ack script that surfaces HIE RegistryError responses. See Sending a CDA Document to an HIE.

Base URL¶

The base URL of the Google Cloud Healthcare API service (default https://healthcare.googleapis.com/). The Host, Port, Location, Use HTTPS, and Endpoint URL fields are not used. The URL for each call is built from the base URL plus the datastore-specific path.

Datastore(s)¶

Configures one or more Google Cloud Healthcare datastores (FHIR stores, HL7v2 stores, or DICOM stores) reachable through this connection. For each datastore enter the location, dataset, datastore ID, and type. The Test button next to a datastore submits a probe call to verify the credentials and path. Save any pending changes before testing.

Response streaming¶

Web Service mapping functions that use a Google Cloud Healthcare API connection support response streaming to a file. See Stream to File.

Endpoint URL¶

The base URL of the Open AI API (default https://api.openai.com/). The Manually set the endpoint URL checkbox is enabled by default.

Operations¶

A tree of Open AI operations (chat completions, embeddings, image generation, etc.) and the AI models available for each. Expand a category and check the operations the connection should expose; for each selected operation, pick one of the default models or type a custom model name.

Operation URLs and path parameters¶

For a selected operation, QIE builds the request URL by joining the connection's Endpoint URL with the operation's relative path (for example v1/responses), always using a single / separator and preserving any port. When an operation's path contains a parameter such as v1/files/{file_id}, QIE resolves that parameter from the message cache at send time. Set the matching key (for example file_id) in a mapping script before the message reaches the destination.

To bypass the built URL, enable Override URL on the Web Service mapping function or destination node and enter the full request URL; QIE then sends that URL verbatim and does not append the operation's relative path. Changes to the override setting are recorded in the connection's revision history.

Response streaming¶

Web Service mapping functions that use an Open AI API connection support response streaming to a file, which is particularly useful for large model-generated completions or binary file downloads. See Stream to File.

Host, Port, and Location¶

Used to pre-populate the Endpoint URL for the legacy QIE-to-QIE web service protocol. Default port is 8081 and default location is ws/QIE.

Because this type is deprecated, the Allow concurrent calls, SSL, and Static HTTP Headers sections are not available. Use a REST-based connection for new integrations.