FQL is a query language that allows you to retrieve, filter and project data from any data source containing FHIR Resources. It brings the power of three existing languages together: SQL, JSON and FhirPath. It allows you to create tables and is useful for gaining insight and perform quality control.
Invocations
URL: [base]/Questionnaire/$populatelink
URL: [base]/Questionnaire/[id]/$populatelink
Parameters (In)
| Name | Cardinality | Type | StructureDefinition | Documentation |
| identifier | 0..1 | Uri | A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories. | |
| questionnaire | 0..1 | Questionnaire | The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion | |
| questionnaireRef | 0..1 | Reference | Questionnaire | The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire. |
| content | 0..* | Reference | Resources containing information to be used to help populate the generated HTML form. 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.) | |
| local | 0..1 | Boolean | 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. |
Return Values (Out)
| Name | Cardinality | Type | Documentation |
| link | 1..1 | Uri | The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire |
| issues | 0..1 | OperationOutcome | A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter |
While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page 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 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. The web form is responsible for pruning 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.