Structured Data Capture
3.0.0 - STU 3 International flag

This page is part of the Structured Data Capture FHIR IG (v3.0.0: STU 3) based on FHIR R4. This is the current published version. 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: 3.0.0
Standards status: Trial-use Maturity Level: 3 Computable Name: SDCFormArchiver

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

SDC Form Archiver

(Requirements Definition Capability Statement)

Canonical URL: http://hl7.org/fhir/uv/sdc/CapabilityStatement/sdc-form-archiver Published: 2015-09-03 (draft)

Published by: HL7 International - FHIR Infrastructure

This profile defines the expected capabilities of the SDC Form Archiver role when conforming to the S&I Framework's 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.

General

FHIR Version: 1.0.0
Supported formats: xml, json

REST client behavior

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 SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete Operations
QuestionnaireResponse (Profile) SHALL SHOULD MAY
Binary SHOULD MAY MAY
DocumentReference SHOULD MAY MAY
Provenance SHOULD

General interactions

Name Capability Statement Description
  transaction SHOULD

Modes:

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



QuestionnaireResponse

Profile: http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponse

Interactions

Name Conformance Description
  create SHALL

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

  update SHOULD

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

  delete MAY

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.



Binary

Interactions

Name Conformance Description
  create SHOULD

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

  update MAY

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

  delete MAY

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.



DocumentReference

Interactions

Name Conformance Description
  create SHOULD

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

  update MAY

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

  delete MAY

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.



Provenance

Interactions

Name Conformance Description
  create SHOULD

Allows submitting a Provenance record associated with a particular QuestionnaireResponse.