Initiative Overview

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.
• Solicit completion of a form

Capability Statements

FHIR Capability statements define the expectations for 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 three other roles that are not defined by this implementation guide:

• Clinical or Administrative Data Source - This is an Electronic Health Record (EHR) 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.
• Task Manager - A repository of FHIR Tasks that represent requests for a user to perform an action - in this case complete (or finish completing) a form.

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

Figure 1: Role operations

Workflows

There are two primary workflows that fall within the scope of the SDC implementation guide - form creation/curation and form filling. There's a third workflow not strictly within the scope of SDC that is also discussed - form solicitation.

Form curation

Figure 2: Form Curation Workflow

In form curation, as shown in Figure 2, 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.

Form filling

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 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.

Form solicitation

Figure 4: Form Solicitation Workflow

In this workflow, a clinical, research or other system that wants a user to complete a form creates a Task instance which behaves as a "to do" item for the specified 'owner'. There are two different options in terms of the nature of the Task. The Task could specifically say "Please fill out this Questionnaire" or it could say "please fulfill this ServiceRequest where the ServiceRequest in turn seeks fulfillment of a specific Questionnaire. The recommendation is to use the Task-only approach unless there's a genuine need for a formal 'order' associated with the request - e.g. to support payment, to encourage compliance, etc.

The SDC Task profile sets expectations for an instance regardless of which approach is chosen.

Task-based solicitation

In this mode, a Task is initiated that indicates the Questionnaire to be completed by specifying the Questionnaire itself as a Task.input. (In R5, if Task.focus is expanded to support canonical, this will likely change to use Task.focus instead.) This implementation guide defines a specific code to use for the Task.code that defines the expected action on that focus - i.e. to create a completed QuestionnaireResponse instance that is valid against the specified Questionnaire. The questionnaire from the http://hl7.org/fhir/uv/sdc/CodeSystem/temp code system. (This code will eventually be replaced with an 'official' code in an externally maintained code system - e.g. LOINC, SNOMED or something in terminology.hl7.org.) The Task identifies the Questionnaire to be completed and also provides information such as why the Questionnaire needs to be completed, who is to complete it, who is asking for it, when it needs to be done, etc.

While this approach doesn't rely on the existence of an order to specify the Questionnaire to be completed, there might still be an 'order' associated with the Task that provides an overall authorization that drives the need for the form to be completed. For example, a pre-surgery form or a satisfaction survey might point to a ServiceRequest that had ordered the surgery. In this case, the relevant Request resource will be referenced by the Task.basedOn element. In this case, the 'Request' would not dictate the specific Questionnaire, but would instead typically specify a higher level action (appointment, medication, surgery, therapy, etc.). An example for Task-based solicitation can be found here.

Request-based solicitation

In this situation, the Questionnaire to be filled out is the primary focus of the order and is explicitly identified in the 'Request' - which in this case will always be a ServiceRequest. The same code is used as was used on the Task, however with ServiceRequest, the Questionnaire to be completed is specified in an SDC-specific extension. There can only be one Questionnaire specified. A Task is then created to seek fulfillment of the order. It is possible that the order might solicit the Questionnaire to be filled out multiple times. However, there will be a separate Task for each occurrence. The reason, expected timing, intended performer, etc. may be fully specified by the ServiceRequest, might only be specified by the Task, or might be defined at a high-level by the ServiceRequest and then refined by the Task.

As with the Task-based approach, a ServiceRequest might in turn point to a 'higher-level' Request that is fulfilled, in part, by the ServiceRequest seeking the filling of the form. This higher-level ServiceRequest might be an order, but could also be a proposal or plan. For example, a decision support recommendation. An example for Request-based solicitation can be found here.

General considerations

Regardless of the type of Task used, there are a number of common considerations when using the Task to solicit activity. The first is how the Task is delivered. The Workflow Management section of the core specification provides a number of mechanisms for communicating the Task to the system responsible for acting upon it, including:

• Posting to the placer system and having the filler system either poll or subscribe to see the data. This would work best where the client is a light-weight patient app with known locations to check for 'to do' items on.
• Direct post to the filler system and having the placer system either poll or subscribe to monitor the Task for activity. This would work best where the fulfiller has a known server endpoint and there might be multiple systems seeking Questionnaires or other tasks to be completed.
• Posting to an intermediary and having both the placer and filler systems either poll or subscribe to monitor for new Tasks and updates to existing ones. This works well if there's a natural intermediary trusted by both sides and the could be many placing and filling systems.
• Various other mechanisms including messaging and operations.

In addition to delivery, there are several other considerations:

• Is the Questionnaire assigned to a specific individual to complete or is it open-ended? In most cases, when creating a Task to get a Questionnaire filled out, there will be a specific individual who is supposed to complete the QuestionnaireResponse. This individual will be identified as the 'owner' of the Task. However, in some cases, who is to complete the form may be open-ended. In this latter case, both the owner and performerType, the owner omitted and the performerType specified or the owner specified with a higher-level performer (e.g. an Organization or a CareTeam, with the expectation that the actual QuestionnaireResponse will be completed by someone who is a 'member' of the specified group. Even if the Task is assigned to a specific individual (e.g. a Patient), workflow processes might allow for the owner to be changed or the QuestionnaireResponse author to differ from the assigned Task owner. E.g. A form filled out by a next-of-kin in situations where the patient is unable.
• If the Questionnaire could be filled out by a variety of people, then the 'task-claiming' portion of the workflow might be relevant where a potential filler might change the status to 'received' and changing the owner prior to deciding whether to accept or reject the Task.
• In most cases, the individual to whom the Task is assigned has the ability to say 'yes' (status = 'accepted') or 'no' (status = 'refused'), possibly indicating a statusReason to indicate why they will not or cannot fill out the Questionnaire. Workflow should allow for this possibility of rejection and decide whether standardized reason codes should be used. SDC does not impose any constraints at this time.
• Even after accepting a Task and agreeing to complete a Questionnaire, it is possible for the action to fail. The user might start and be unable to complete for a variety of reasons. If the Task has passed the time where gathering the information would be helpful (typically communicated as the Task.executionPeriod.end), the status might be changed to 'failed' by either the placer or filler system.

• Once the QuestionnaireResponse has been created, it needs to be stored somewhere and linked as a Task.output. Again, SDC has defined an explicit output code - questionnaire-response from the http://hl7.org/fhir/uv/sdc/CodeSystem/temp code system. This code will also be replaced with an 'official' code once the business requirements have been better confirmed.

  If the 'responseEndpoint' Task.output is present, the QuestionnaireResponse should be POSTed to all of the specified endpoints. Similarly, if the sdc-questionnaire-endpoint extension is present on the Questionnaire, it should be POSTed to those endpoints as well. If any of those endpoints are simple RESTful locations (i.e. ending in QuestionnaireResponse) and the corresponding server supports the read operation, then that endpoint can be used as the target of the 'responseEndpoint' reference. If there are no specified endpoints in either the Task or the Questionnaire, or if all of the endpoints specified are write-only or operation endpoints such as $process-response, then the QuestionnaireResponse will need to be posted elsewhere - typically on the same server as the Task, but it can be elsewhere. It obviously SHOULD be accessible to the system that initiated the Task.

• A QuestionnaireResponse may need to be stored before it has been marked as 'complete' - for example if the user has partially completed the form and then needs to save their work to continue later. This QuestionnaireResponse SHOULD be pointed to as the 'questionnaire-response' Task.output, allowing it to be easily re-loaded on resumption of the Task. The QuestionnaireResponse.status and the Task.status would not be set to 'completed' until the user had decided the form was 'done' and it successfully met validation criteria. Submission to any indicated endpoints would typically not occur until the QuestionnaireResponse was deemed 'completed'.