Structured Data Capture 2.5.0 - Edition 3(STU), For Comment 2018Sep Ballot

This page is part of the Structured Data Capture FHIR IG (v2.5.0: STU 3 Ballot 1) based on FHIR v3.5.0. The current version which supercedes this version is 3.0.0. For a full list of available versions, see the Directory of published versions

The Structured Data Capture (SDC) Initiative identifies and recommends standards for the interoperable representation and transmission of the following:

  • Standard form designs;
  • Query for form;
  • Return a form;
  • Submit completed form data to an external data repository.

FHIR Capability statements define the expectations for particular system "roles" within an SDC environment. To be considered SDC-conformant, a system must adhere to the requirements defined by at least one of these statements. Some systems might choose to comply with more than one.

  • SDC Form Designer - System responsible for creating and editing form designs
  • SDC Form Filler - System responsible for capturing user form input to produce partially or fully completed forms
  • SDC Form Manager - Repository for form definitions. May also perform pre-population
  • SDC Form Response Manager - Searchable repository for storage and retrieval of completed and partially completed forms.
  • SDC Form Receiver - Write-only destination to which forms are sent for processing
  • SDC Form Archiver - Write-only system responsible for archiving completed forms as well as works in progress

In addition to the above, there are two other roles that are not defined by this implementation guide:

  • Clinical or Administrative Data Source - This is an Electronic Medical Record (EMR) or similar system that is a repository of data potentially relevant for populating a form that might be queried as part of the form population process. Responsibilities would be to respond to queries from the SDC Form Filler and/or SDC Form Manager during the form population process
  • Data Element Source - A repository of FHIR StructureDefinitions (resources, data types, profiles, and/or logical models) or CodeSystems that can be used to look up item definitions or codes to help in defining questions and groups.

The relationship between these roles and a summary of how they can interact is shown in Figure 1.

Role operations

Figure 1: Role operations

There are two primary workflows that fall within the scope of the SDC implementation guide - form creation/curation and form filling.

Diagram showing interaction between Form Designer, Form Manager and Data Element Registry

Figure 2: Form Curation Workflow

In form curation, the Form Designer interacts with both the Form Manager and the Data Element Registry to create, edit and update forms, including identifying and defining associated terminologies and data elements. This is an iterative process where an initial version is created and then subsequently updated and maintained, eventually changing status to active and later retired.

The more significant (and complex) workflow in SDC is to complete (and potentially submit) a completed questionnaire response.

Generic Workflow

Figure 3: Form Filling Workflow

Note: The diagram depicts the optional storage of the completed form by the EHR. This can occur when the EHR stores a copy of the form as they send it to the External Data Repository or by the external data repository returning a copy of the form to the sender who can store an internal version of the form.

The driver of this workflow is the Form Filler system. It retrieves a form (Questionnaire) from the Form Manager. It may also request that the Form Manager generate an initial QuestionnaireResponse, potentially partially populated with information known by the Form Manager, supplied by the Form Filler or queried from the underlying EHR. The Form Filler could generate the QuestionnaireResponse itself without the assistance of the Form Manager and in either case could partially fill in the response based on information known by the form filler.

When as much of the questionnaire response as possible has been filled in by automated means, the form is displayed to an end-user who reviews and edits the automatically populated content as well as completing those portions of the form that were not populated automatically. In some cases, the form may be stored locally or using a Form Response Manager to allow a user to stop and resume editing at a later point.

The Form Filler (possibly with help from the Form Manager) is responsible for verifying that a completed form is actually complete and valid against the corresponding Questionnaire. Once valid, the form filler submits the form to one or more target repositories (Form Receiver allows the completed form to be subsequently retrieved, Form Archiver does not) and/or stores the completed form itself. (Note - Form Receivers may perform validation on forms prior to consumption, Form Archivers typically will not.) The receiver of the completed form might then extract the data into relevant FHIR resources.