While it is theoretically possible for a QuestionnaireResponse 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.

When creating an "empty" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with "enableWhen", "display" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values.

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 respondent, 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.