A Protocol for Interactive Services in FHIR

In developing Health IT software, it's fairly common to develop solutions that have to interact with interactive web sites.  When all that is needed is for those web sites to interact with a user, this is fairly easy to work out.  However, when the interaction also needs to communicate to the "back end" to convey the outcome of what the user did, it is a bit more complicated.

There are several use cases for this kind of interaction that I've seen in the past, and one that most recently came up in the context of the Guideline Appropriate Ordering profile from IHE.

The first of the use cases is patient selection:
In this use case, a patient is registering or being admitted for care to an institution.  In this case, the patient name, date of birth, and gender are provided at the time of registration.  One or more pre-existing patient records are located by the system.
The user has a few choices:

1. Select and confirm the appropriate record (if only one record is found, the selection step is skipped and that record is simply selected, if no records are found this option isn't available).
2. The user can search again using different information.
3. The user can create a new patient record.
4. The user can cancel the registration process.

The second of these is document searching and viewing.  In this case, document search criteria are used to identify candidate documents.  Pretty much the same options are available to the user, with a different end result:

1. They can select a particular document to view (If one document is found, it may be automatically selected; if no documents are available, this option isn't available).
2. The user can search again using different criteria.
3. The user can cancel (this use case doesn't have the create option).

The third of these use cases is clinical decision support on the appropriateness of the order.  In this case, the following options might be presented:

1. The order might simply be approved, in which case the user may simply be asked to confirm the order details.
2. The user might be asked for more information about the patient for whom the order is being made (e.g., for a MRI where the indication is headache, the CDS system might ask if this is the worst headache the patient has ever experienced).
3. The order might not be approved, in which case the user may be requested to use a different service, or to override the CDS result.
4. The user can cancel.

The previous may not seem to be obvious use cases, so I'll toss out another one that is pretty much accepted across the IT spectrum: User Authentication.  In this case, a user authenticates with an external system and the external system conveys a token back to the "back end" requesting the authentication.

For the IHE GAO Profile (the third use case above), we borrowed some design features from specifications that support authentication.  

1. The client makes a request to an interactive service through a known (preconfigured or returned in some previous interaction).  It also passes in a URL to which the interactive session will be redirected when the server has finished interacting with the user.
2. The interactive session continues as a normal web interaction.  
3. When the server has finished interacting with the user, it passes back a redirection request using that URL, and some URL parameters to tell the page that it was redirected to what the status of the request was (canceled, completed, error, et cetera), and where to get the full details of the result.

It occurs to me that this could become a general pattern for interactive services that might be specified somewhere in an Implementation Guide.  What do you think?  Would this be a good pattern to specify for FHIR?  Or more generally?  What other features should be considered in this interactive framework?