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

This page is part of the Structured Data Capture FHIR IG (v4.0.0-ballot: STU 4 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 3.0.0. For a full list of available versions, see the Directory of published versions

CapabilityStatement: SDC Form Archiver

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

This profile defines the expected capabilities of the ''SDC Form Archiver'' role when conforming to the S&I Framework's [[index.html Structured Data Capture FHIR implementation guide]]. This role is responsible for persisting (archiving) completed or partially completed forms ([[QuestionnaireResponse]] resource instances). These instances may be submitted individually or in a bundle together with [[Provenance]] information providing details about the completion of the questionnaire response. In some cases [[Binary]] or [[DocumentReference]] resources might also be submitted to convey source information used in the population of the questionnaire response.
The purpose of this role is to capture "work in progress" for archival reasons. There is no expectation that submitted form data is subsequently made available for retrieval (at least not in the same format), though it might be made available through out-of-band mechanisms.

Raw OpenAPI-Swagger Definition file | Download

Generated Narrative: CapabilityStatement sdc-form-archiver

SDC Form Archiver

  • Implementation Guide Version: 4.0.0-ballot
  • FHIR Version: 1.0.0
  • Supported Formats: xml, json
  • Supported Patch Formats:
  • Published on: 2015-09-03
  • 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.

FHIR RESTful Capabilities

Mode: client

The [[QuestionnaireResponse]] may be sent as a single instance or as a FHIR [[Bundle]] also containing [[Provenance]] resources providing details on the sources of information. A Bundle submission might also include [[Binary]] and/or [[DocumentReference]] instances referring to the data used to populate the form. A Form Archiver must support persisting, searching and retrieving those resources.

Security

Implementations must meet the general security requirements documented in the [[security.html|SDC implementation guide]].

Summary of System-wide Interactions
  • SHOULD support the transactioninteraction described as follows:

    Allows submission of a [[QuestionnaireResponse]] together with [[Provenance]] and other supporting resources as a single unit of work.

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 Conformance: SHALL QuestionnaireResponse

Profile Conformance
SHALL
Reference Policy

Interaction summary
  • SHALL support
    create

    Allows archiving (storing) a completed or partially-completed form

  • SHOULD support
    update

    Allows updating a previously archived form. (Systems may place rules on who can update forms and under what circumstances).

  • MAY support
    delete

    Allows removal of an archived form from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove a submitted response and under what circumstances.

Resource Conformance: SHOULD Binary

Core FHIR Resource
Binary
Reference Policy
Interaction summary
  • SHOULD support
    create

    Allows storage of a binary (generally containing information used in the completion of a [[QuestionnaireResponse]]). The data might be in a variety of forms.

  • MAY support
    update

    Allows updating a previously submitted binary data. (Systems may place rules on who can update binary data and under what circumstances).

    delete

    Allows removal of binary data from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove binary data and under what circumstances.

Resource Conformance: SHOULD DocumentReference

Core FHIR Resource
DocumentReference
Reference Policy
Interaction summary
  • SHOULD support
    create

    Allows storage of a document reference (generally containing information used in the completion of a [[QuestionnaireResponse]]).

  • MAY support
    update

    Allows updating a previously submitted document reference. (Systems may place rules on who can update document references and under what circumstances).

    delete

    Allows removal of document references from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove document references and under what circumstances.

Resource Conformance: SHOULD Provenance

Core FHIR Resource
Provenance
Reference Policy
Interaction summary
  • SHOULD support
    create

    Allows submitting a Provenance record associated with a particular [[QuestionnaireResponse]].