Release 5

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4

Example OperationDefinition/Resource-convert (Narrative)

FHIR Infrastructure Work GroupMaturity Level: N/AStandards Status: InformativeCompartments: No defined compartments

This is the narrative for the resource. See also the XML, JSON or Turtle format.

Note that this is the formal definition for the convert operation as an OperationDefinition on Resource. See the Operation documentation


URL: [base]/$convert

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INresource1..1Resource

The resource that is to be converted

OUTreturn1..1Resource

The resource after conversion

While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:

  • converting resources from one version to another
  • restructuring information in a resource (e.g. moving method into/out of Observation.code)
  • extracting data from a questionnaire
  • converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).

These variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.

For this reason, implementers should be aware that:

  • the return resource type may be different from the resource parameter resource type (for example, it might be a bundle)
  • binary resources may be represented directly using some other content-type (in other words, just post the content directly)

Implementers are encouraged to provide feedback to HL7 about their use of this operation


 

 

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.