Existing Wording: Each Use Case includes an overall description. It provides technical specifications for one or more options showing how FHIR-based mechanisms can be used to accomplish the needed information exchange.

Business Actors, Technical Actors and Information Exchange Options

The use cases descriptions in the implementation guide focus on business actors (organizations and people who need to share information). The information exchange mechanisms are specified using technical actors (systems involved in making digital information exchange possible). The use of technical actors makes specification of the information sharing mechanisms more generalized. It makes it possible to describe situations where a business actor may use a system that plays different technical roles with respect to how data is shared. For example, a payer's system could play the role of both an Information Sender as well as an Information Request Sender for a request-based information exchange.

For a data query, the technical actors are an Information Client and an Information Server. For an unsolicited communication there is an Information Sender and an Information Recipient. For an asynchronous solicited communication, an Information Request Sender sends a communication request to an Information Request Recipient. The system acting as the Information Request Recipient processes the request as a task that gets completed, then acting as an Information Sender returns information to the Information Recipient (or Recipients) indicated in the communication request. The system that plays the role of the Information Request Sender may or may not be an Information Recipient. Other systems may play the role of Information Recipient.

Paradigms and Payloads

The implementation guide makes use of multiple FHIR data sharing paradigms. It utilizes the transaction, messaging, and documents paradigms to facilitate bi-directional digital information exchange between systems used by organizations and individuals. The transaction paradigm supports RESTful APIs for querying data and documents directly. The messaging paradigm supports asynchronous communication requests for information and direct communication of information that needs to be shared or has been requested. The documents paradigm is used to represent information organized in documents. Documents can be attached as the payload of a message. Specific types of documents or data may be requested and are communicated to supply recipients with needed information.

Comment:

While this section describes what one would expect to have described for each of the following use cases, none of the use cases actually does more than provide a "storyboard" with under-specified business actors. There are no clear technical actors or information exchange interactions described. Paradigm/Payloads are also anecdotally stated in the storyboards - and only C-CDA is called out as a payload. Only the first use case for CDex Improve Care Coordination has an entry for what this section promises:

Information Exchange Mechanism to Support? Need to explain what exchange mechanisms are SHALL, SHOULD, or MAY to be able to support this use case? http://hl7.org/implement/standards/fhir/us/davinci-cdex/2019Jun/CDex_Improve_Care_Coordination.html.

This section should have interaction diagrams as well as descriptions for all pertinent interactions as listed @ Information Exchange Interactions and Specifications - http://hl7.org/implement/standards/fhir/us/davinci-cdex/2019Jun/Information_Exchange_Interactions_and_Specifications.html. There's just too much complexity for readers trying to match up the interactions/actors with the paradigm/payloads for these complex use cases.

Summary:

While this section describes what one would expect to have described for each of the following use cases, none of the use cases actually does more than provide a "storyboard" with under-specified business actors