This page is part of the FHIR Specification (v1.2.0: STU 3 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
Conformance-sdc-form-designer
This is the narrative for the resource. See also the XML or JSON format.
SDC Form Designer
(Requirements Definition)
Published: 2014-07-06 (draft)
Published by: U.S. Office of the National Coordinator (ONC)
This profile defines the expected capabilities of the SDC Form Designer role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for defining forms (Questionnaire resource instances) that include references to DataElement resouces which define the meaning of particular questions and can be used to aid in pre-populating and auto-populating forms.
General
FHIR Version: |
1.2.0 |
Supported formats: |
xml, json |
REST behavior
The Questionnaire resource is used to create and maintain SDC-compliant forms. The DataElement resource is used to look-up existing data elements that can be referenced in forms. Optionally, DataElements can also be created and maintained in conjunction with form editing. This is an optional feature as not all environments will provide support for data element definitions from form authors. The ValueSet resource is used to capture allowed values for questions that are to be answered from a pre-defined list of values. For some forms, some or all of the referenced value sets will be handled as 'contained' resources, meaning the value set exists only in the context of the Questionnaire and cannot be referenced or maintained without also updating the form. However, systems should support value set re-use across questionnaires. (Version-specific referencing can be used to avoid value sets from changing independent of the referencing Questionnaire.)
Security:
Implementations must meet the general security requirements documented in the SDC implementation guide.
Resource summary
Interactions
Name |
Conformance |
Description |
search-type
|
SHALL |
Allows discovery of existing questionnaires for editing
|
read
|
SHALL |
Allows retrieval of a specific questionnaire by id
|
create
|
SHALL |
Allows submission of a new form design
|
update
|
SHALL |
Allows revision of an existing form design. Note that certain types of updates may necessitate retiring the existing form and defining a new one.
|
history-instance
|
SHOULD |
Allows review of changes to questionnaire over time
|
vread
|
SHOULD |
Allows retrieval of a historical version of a questionnaire
|
delete
|
MAY |
Not all servers will support deletion of forms. Status change to 'retired' will be more typical, though deletion of draft profiles may keep repositories cleaner.
|
validate
|
MAY |
Allows verification that form is valid prior to submission - useful for some workflows.
|
Interactions
Name |
Conformance |
Description |
search-type
|
SHALL |
Allows discovery of existing value sets for use by questions in a form
|
read
|
SHALL |
Allows retrieval of a specific value set by id
|
create
|
SHALL |
Allows definition of a new value set used by one or more questions
|
update
|
SHALL |
Allows existing value sets referenced by a form to be maintained. Note that certain types of updates may necessitate retiring the existing value set and defining a new one.
|
history-instance
|
SHOULD |
Allows review of changes to a value set over time
|
vread
|
SHOULD |
Allows retrieval of a historical version of a value set
|
delete
|
MAY |
Not all servers will support deletion of value sets. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.
|
validate
|
MAY |
Allows verification that a value set is valid prior to submission - useful for some workflows.
|
Interactions
Name |
Conformance |
Description |
search-type
|
SHALL |
Allows a user to search for existing data elements for re-use in a form design
|
read
|
SHALL |
Allows retrieval of data elements referenced in an existing form design
|
vread
|
SHOULD |
Allows viewing of specific versions of a data element if the form references a specific version
|
history-instance
|
SHOULD |
Allows review of changes to a data element over time
|
create
|
MAY |
Allows defining new data elements for subsequent re-use while creating and editing forms
|
update
|
MAY |
Allows maintaining data elements while creating and editing forms. Note that certain types of updates may necessitate retiring the existing data element and defining a new one.
|
delete
|
MAY |
Allows maintaining data elements while creating and editing forms. Note that not all servers will support deleting data elements.
|
validate
|
MAY |
Allows maintaining data elements while creating and editing forms - user can check that proposed data element is valid prior to submission
|
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.