This page is part of the Structured Data Capture FHIR IG (v1.6: STU 2 Ballot 1) based on FHIR v1.6.0. . For a full list of available versions, see the Directory of published versions

This is a pre-release of a future version of SDC (expected to be STU 2). The current version is STU 2.
For a full list of available versions, see the Directory of published versions .

3 SDC Form Designer

Formats: XML, JSON, Turtle

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: $ver$
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 and CodeSystem resources are 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 (and possiblye code systems) 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 and code system 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

Resource Search Read Read Version Instance History Resource History Create Update Delete
Questionnaire (Profile) SHALL SHALL SHOULD SHOULD SHALL SHALL MAY
ValueSet (Profile) SHALL SHALL SHOULD SHOULD SHALL SHALL MAY
CodeSystem (Profile) SHALL SHALL SHOULD SHOULD SHALL SHALL MAY
DataElement (Profile) SHALL SHALL SHOULD SHOULD MAY MAY MAY


Questionnaire

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.


ValueSet

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.


CodeSystem

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing code systems for use by questions in a form
  read SHALL

Allows retrieval of a specific code system by id
  create SHALL

Allows definition of a new code system used by one or more questions
  update SHALL

Allows existing code systems referenced by a form to be maintained. Note that certain types of updates may necessitate retiring the existing code system and defining a new one.
  history-instance SHOULD

Allows review of changes to a code system over time
  vread SHOULD

Allows retrieval of a historical version of a code system
  delete MAY

Not all servers will support deletion of code systems. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.


DataElement

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.