Structured Data Capture
4.0.0-ballot - STU 4 ballot International flag

Structured Data Capture, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 4.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/sdc/ and changes regularly. See the Directory of published versions

CapabilityStatement: SDC Form Response Manager

Official URL: http://hl7.org/fhir/uv/sdc/CapabilityStatement/sdc-form-response-manager Version: 4.0.0-ballot
Standards status: Trial-use Maturity Level: 4 Computable Name: SDCFormResponseManager
Other Identifiers: OID:2.16.840.1.113883.4.642.40.17.13.6

This profile defines the expected capabilities of the ''SDC Form Response Manager'' role when conforming to the S&I Framework's [[index.html Structured Data Capture FHIR implementation guide]]. This role is responsible for providing read/write access to QuestionnaireResponses. This is typically to support light-weight clients that want to be able to complete forms but do not have local storage to save work in progress.

Raw OpenAPI-Swagger Definition file | Download

SDC Form Response Manager

  • Implementation Guide Version: 4.0.0-ballot
  • FHIR Version: 1.0.0
  • Supported Formats: xml, json
  • Supported Patch Formats:
  • Published on: 2014-07-06
  • Published by: HL7 International / FHIR Infrastructure

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

This CapabilityStatement instantiates the CapabilityStatement SDC Form Manager

FHIR RESTful Capabilities

Mode: server

Security

Implementations must meet the general security requirements documented in the [[security.html|SDC implementation guide]]. Systems may wish to ensure that QuestionnaireResponse instances are only accessible to the user (or at least the organization) who was responsible for creating them.

Summary of System-wide Interactions

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCDH-ISearches_include_revincludeOperations
QuestionnaireResponsehttp://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponseyyyyyy

Resource Conformance: SHALL QuestionnaireResponse

Base System Profile
SDC Standard Questionnaire Response
Profile Conformance
SHALL
Reference Policy

Interaction summary
  • SHALL support
    create

    This creates an initial version of a QuestionnaireResponse - a completed form for a particular subject as of a particular point-in-time

    update

    This allows revision of a QuestionnaireResponse. Typically this will happen while the response is still 'in-progress'. If it occurs after the response has been marked as 'final', the status should change to 'amended'. Updates can also be used to change the status to 'entered-in-error' or other values. Servers may choose to enforce business rules around what state transitions are supported and for which users.

    search-type

    This allows a user to find previously created responses - whether created by themselves or others. For thin clients without persistence, this feature is essential to allow them to find a draft of a previously created response

    read

    This allows a user to retrieve a previously stored response by id. (Some thin clients may have limited persistence -e.g. cookies - that could be used to store an id and later retrieve a work-in-progress questionnaire response

  • SHOULD support
    delete

    This removes a previously submitted QuestionnaireResponse. In addition to (or instead of) supporting direct requests for deletion, some servers may automatically purge QuestionnaireResponses that have been in existence and unmodified for a period of time. Deletions may not be a physical delete and it may still be possible to access older versions of a deleted response

  • MAY support
    history-instance

    This allows a user to look at previous versions of a response. It supports identifying what changes were made and potentially retrieving an older version to use as a starting point in the event that data has accidentally been removed or changed

Documentation

This allows QuestionnaireResponses to be created, updated and retrieved. Note that storing a QuestionnaireResponse does not imply any execution of behavior on the basis of the stored data.