2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). 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 R3 R2

4.27.12 Resource Questionnaire - Operations

This resource has 1 operation associated with it. For more information about operations, including how they are invoked, see Operations.

4.27.12.1 Populate Questionnaire

Generates a QuestionnaireAnswers instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire.

If the operation is not called at the instance level, one of the identifier or questionnaire 'in' parameters must be provided. (If called at the instance level, these parameters will be ignored.)

The response will contain a QuestionnaireAnswers instance based on the specified Questionnaire and/or an OperationOutcome resource with errors or warnings.

The QuestionnaireAnswers instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.

Population of the QuestionnaireAnswers with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions. This might be through Questionnaire.group.question.code, through extensions such as the [[http://hl7.org/fhir/ExtensionDefinition/questionnaire-deReference|deReference]] extension or through us of the [[ConceptMap]] resource.

Regardless of the mechanism used to link the questions in a questionnaire to a "known" mapable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population. I.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertable, etc.

Formal Definition (as a OperationDefinition).

URL: [base]/Questionnaire/$populate

URL: [base]/Questionnaire/[id]/$populate

In Parameters:
NameCardinalityTypeProfileDocumentation
identifier0..1uri

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

questionnaire0..1Questionnaire

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

subject1..1Any

The resource that is to be the QuestionnaireAnswers.subject. The QuestionnaireAnswers instance will reference the provided subject. In addition, if the local parameter is set to true, server information about the specified subject will be used to populate the instance.

content0..*string

Resources containing information to be used to help populate the QuestionnaireAnswers. These may be FHIR resources or may be Binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

local0..1boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

Out Parameters:
NameCardinalityTypeProfileDocumentation
return1..1QuestionnaireAnswers

The partially (or fully)-populated set of answers for the specified Questionnaire

Note: as this the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource

While it is theoretically possible for a QuestionnaireAnswers instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.

Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondant, answering only those questions that are enabled based on previously answered questions. However doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place.

Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.