Existing Wording: To facilitate this, the DTR application should allow users to create tasks. The details of the task should be represented by a FHIR Task resource. The DTR application should communicate the task information to the EHR system using the FHIR create interaction. The task resource is meant to act as a "to-do" item for the clinician or their staff, not substitute an actual order.

The DTR application should attempt to prepopulate as much of the Task resource as it can based on the context of the application. Task.description may draw from the text available in the currently active Questionnaire.item.text.

The questionnaire should be able to suspend completion until all tasks are completed. How the application is suspended is left to the implementer, but the state of the questionnaire should be preserved. The DTR application launches with a unique state id, which could be used to preserve state until the questionnaire resumes.

Comment:

Rather than creating a task, if an order can be placed, enable placing the order. In the example given, rather than creating a task to order a sleep study, let the user order the sleep study / referral to the sleep clinic. Also, not sure you really want the questionnaire state to be persisted. Let's say, for the oxygen order example, you need to first order a required test. Then let's say it's now 2 months later because it took some time to do it and for the patient to be re-evaluated. There's a good chance a lot of the other results, like oxygen saturation info, has changed. It may be useful to remember the manually entered data, at least to show what had been previously entered, but it would be risky to assume manually entered data hasn't changed since the last entry, and for sure if there is updated structured EHR data available, that should be pulled rather than the old one being persisted and re-used. This one's pretty complicated, and probably use case dependent. Would be very cautious about mandating a specific approach.

Summary:

Let users place required orders than creating a task for others (perhaps themselves) to place those orders later. Be careful about state persistence.