web stats
Skip to end of metadata
Go to start of metadata

After deploying a FHIR Listener channel, the "/metadata" endpoint will already be configured to return an auto-generated capability statement. The FHIR server is now technically up and ready to receive requests. The next step is to use the source map information the connector provides, create your transformers and destinations, and return the appropriate responses.

If you send a FHIR request to your channel (for example, POSTing a Patient resource), you'll see in the message browser that certain FHIR-specific variables are automatically injected into the source map. These are the possible variables:

  • fhirInteraction: The inferred interaction for this request (e.g. "create", "read", "update", "delete").
  • fhirType: The type of resource the interaction/request is for (e.g. "Patient", "Binary"). This will be absent for system-level interactions.
  • fhirId: The logical ID of the resource associated with the request. Not all interactions require the client to send an ID, so this may be absent.
  • fhirVid: The version ID of the resource associated with the request. Not all interactions require the client to send a version ID, so this may be absent.
  • fhirCompartmentName: The type of compartment the request is for (e.g. "Patient", "Encounter"). This will only be populated for compartment search interactions.
  • fhirCompartmentId: The logical ID of the compartment resource associated with the request. This will only be populated for instance-level compartment search interactions.
  • fhirOperationName: The name of the operation the request is for. For operation requests the interaction will be "operation" and this variable will contain the actual name of the operation (e.g. "$expand", "$lookup").
  • binaryContentType: Only present for Binary resources. This is the content type of the actual underlying binary data.
  • binaryResourceContentType: Only present for Binary resources. This is the content type of the wrapped Binary FHIR resource.

The above variables (depending on the type of request) will be available throughout your channel. So you can use destination filters (or destination set filtering in the source transformer) to, for example, only send to specific destinations for specific interactions. You might have a destination dedicated to creating resources, one dedicated to reading resources, etc.

  • No labels