Release 4B R5 Final QA

This page is part of the FHIR Specification (v4.3.0: R4B (v5.0.0-draft-final: Final QA Preview for R5 - STU see ballot notes ). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Operation-structuredefinition-questionnaire

Example OperationDefinition/StructureDefinition-questionnaire (Narrative)

FHIR Infrastructure Work Group Maturity Level : N/A Standards Status : Informative Compartments : Not linked to any defined compartments

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

Questionnaire OPERATION: Questionnaire The official URL for

Note that this operation is the formal definition is: http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire Generates a Questionnaire instance based on a specified StructureDefinition , creating questions for each core element or extension element found in the StructureDefinition . If the questionnaire operation is not called at the instance level, one of the identifier , profile or url 'in' parameters must be provided. If more than one is specified, servers may raise as an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a Questionnaire instance based OperationDefinition on StructureDefinition. See the specified StructureDefinition and/or an OperationOutcome Operation documentation resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

URL: [base]/StructureDefinition/$questionnaire

URL: [base]/StructureDefinition/[id]/$questionnaire

Parameters

Use Name Scope Cardinality Type Binding Documentation
IN identifier 0..1 canonical Identifier

A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN profile 0..1 string StructureDefinition ( token )

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url type 0..1 canonical

The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN supportedOnly 0..1 boolean

If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.

OUT return 1..1 Questionnaire

The questionnaire form generated based on the StructureDefinition.

Open Issue : Ideally, extensions should be populated in the generated Questionnaire that will support taking QuestionnaireResponse resources generated from the Questionnaire and turning them back into the appropriate resources.

 

 

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.