Instantiates the eform Workflow by creating a ServiceRequesta as well as all required Tasks, as defined by the Plan Definition.activity[]. The Service Request Questionnaire extension provides the reference(s) to the assoicated Quesstionnaires.

The operation persists all resources derived from the associate Paln Definition in the Repository and then returns a collection Bundle snapshot (plus an optional OperationOutcome).

Instance-level operation on ServiceRequest that changes the businessStatus extension (eForms workflow state) and updates associated Task resources.

Search for questionnaires by assembly expectation

Search for questionnaires by workflow context

Search for tasks by business status

Search for tasks by referenced form (questionnaire)

Search for tasks by workflow step

Communication Profile for OH eForms, based on the R4 version.

Notifications, messages, or other communications related to the eForm workflow (e.g., Form X has been assigned to you, A comment was added to Form Y).

A new Communication resource will be generated to capture the Bi-Directional Communication requirement.

There will be a Subscription Resource which will generate a Subscription each time a Communication is saved in a specific state (proposal: in-progress or completed )

DocumentReference Profile for OH eForms, based on the R4 version. Stores metadata about an attachment that was uploaded to the OTN file service.
This is a valueReference in an item in the QuestionnaireResponse.

Organization Profile for OH eForms, based on the R4 version.

The Organization can be referenced as a Form Initiator, a Form Owner or a Notificaiton Recipient

Patient Profile for OH eForms, based on the R4 version.

The Patient represents the individual who is the subject of the eForm.
This information is retrieved from CMS.

Plan Definition Profile for OH eForms, based on the R4 version.

The Plan Definition represents the Form and Workflow Template. It defines a multi-step process in a shareable and executable way that represents a standard definition for the workflow and composite forms, if applicable. It acts as a manifest, listing all the modular components such as (Questionnaires, Tasks and Organizaiton

PractitionerRole Profile for OH eForms, based on the R4 version.

The PractitionerRole represents a specific set of roles at an Organization,
referenced as a Form Initiator, a Form Owner or a Notificaiton Recipient

Provenance Profile for OH eForms, based on the R4 version.

The Provenance resource is the immutable audit trail of significant events. A new Provenance resource must be created for every significant business action (e.g., form creation, submission, revision, status change, revocation). It meticulously records who did what, when they did it, and to which specific version of a resource the action was applied.

Questionnaire Profile for OH eForms which extends sdc-questionnaire.

Requires the assemble-expectation extensions wiith the expectation that all will beindependent. The assemble-expectation SHALL either be independent-root-or-child to indicate it is a root Questionnaires, or independent-child for all child Questionnaires

One or more Questionnaires comprise the template itself, containing all the questions, answer options, and structure. Questionnaires may be assembled from other sub-Questionnaires utilizing FHIR’s Structured Data Capture’s Modular Forms.

The sub-questionnaire is utilized to indicate that the display item on which this extension appears should be replaced with the referenced Questionnaire

QuestionnaireResponse Profile for OH eForms which extends sdc-QuestionnaireResponse.

This Resource represents a completed (or partially completed) eForm, containing the patient's or practitioner's answers to the questions from the Questionnaire.

Service Request Profile for OH eForms which extends sdc-service-request.

Utilized in Request-based solicitation as defined by SDC, this resource is the initial trigger for the entire workflow.

A ServiceRequest is created by the system once the PlanDefinition is selected.

When the ServiceRequest is created, the system will generate a corresponding Task(s) and to see fulfillment of the request by generating and populating the QuestionnaireResponse resources.

Subscription Profile for OH eForms, based on the R4 version.

A Subscription is a publish-subscribe (pub/sub) mechanism built into the FHIR specification. Subscriptions are defined using the Subscription resource, which specifies what type of data is being subscribed to and how the recipient should be notified.

status - When a Subscription is created by a client, it should have a status of requested. Smile CDR will process this Subscription, and if it is valid, the status will automatically be changed to active, meaning that the Subscription is now being processed. criteria - This is a FHIR search query URL that will be used to determine which resources apply to the Subscription. These resources will trigger a notification when they change. See Criteria below for more information. channel.type - This is the mechanism for delivery, such as rest-hook, websocket, email, sms, or message. See Channel Types for more information. channel.endpoint - For channel types that require the server to initiate a connection to the client, this is the URL of the endpoint to which the server should connect. channel.payload - This is the MIME type encoding to use (e.g. application/fhir+json for JSON data). channel.extension` - Providing an extension allows finer control of subscription handling. Some extensions are channel specific, while others are used to define retry handling.

With Subscriptions enabled, Smile creates a Matching Queue and sends all created/updated QuestionnaireResponse or Communication resources to that queue. This queue is drained by a Subscription Matching module. The Subscription Matcher module uses its FHIR Storage module to retrieve two resource types required for subscription matching: Subscription and SearchParameter. The Subscription Matcher module maintains in-memory caches of both of these resources that it updates from its FHIR Storage module every 60 seconds.

In the requirements, eForms is required to send email notifications whenever a QuestionnaireResponse or Communication Resource is submitted by the form filler to the FHIR Repository. While Smile does offer the ability to trigger email notifications via smtp, OH has a requirement that their AWS Simple Email Service (SES) must be used in order to send notifications. In addition to notifications, Subscriptions will also be utilized to trigger the integration with the OH ObjectStore

AWS SES Delivery - When an QuestionnaireResponse or Communication resource is submitted and the subscription is triggered in the FHIR Server, Smile will trigger a RESTful API call to the AWS SES API.

Object Store Delivery - This Subscription class will automatically invoke an SDC extraction by invoking the QuestionnaireResponse/$extraction operation which will convert the matched QuestionnaireResponse resource into a MessageBundle as defined by the ObjectStore Implementation Guide (IG).

A custom Subscription Delivery class is invoked whenever the matching criteria defined in the Subscription Resource for Object Store integration.

Task Profile for OH eForms which extends sdc-task. Adds the standard task-replaces extension so a new Task can point to the Task(s) it supersedes.

The task is utilized as a central workflow management resource. It tracks the work item of getting a specific eForm completed. It includes custom statuses status, who requested it, and who is currently assigned to work on it, and any communication between parties.

Indicates the business (workflow) status of a ServiceRequest, paralleling Task.businessStatus.

Allowed codes for Task.code in the eForms implementation guide. Combines base FHIR Task codes, SDC codes, and eForms-specific codes.

Permitted values for the businessStatus extension on eForms ServiceRequest and Task resources.

Additional workflow codes used by eForms tasks.

Codes representing the eForms workflow states that appear in the businessStatus extension on ServiceRequest and Task.

Child questionnaire for collecting consent information

Child questionnaire for collecting patient information

A Questionnaire example that is a parent / root

A Questionnaire example that is a child