Fulfillment Manager Conceptual Specification

Link back to solution specification

Overview

Scope

  Comment
    Describe the overall potential scope of the service.  Are any items being specifically excluded from the scope?  Why?

Reason why the service is necessary

  Comment
    Rationale for creating this specification. Consumer viewpoint and the value offered by the work product

Structure of the Service

The Fulfillment Manager Conceptual Diagram is shown below. The variation on the RequestFulfillment return value reflects the business flow difference between ambulatory and in-patient labs - in ambulatory, there is no return value, where in-patient returns a Promise.

Assumptions and Dependencies

 Comment
   Upon what services does this specification depend (underpinning infrastructure, other HL7 services,  etc. Are there any key assumptions that are being made?

Implementation Considerations

  Comment
    Relevant and representative examples of deployment scenarios. Consider representation formalism and the intended audience, not necessarily rigorously expressing the content in UML. This specification in the real world (e.g., relationships to existing infrastructure, other deployed services, dependencies, etc.). Consider the ways that information bindings will be realized through the operations. If necessary, outline a strategy for this binding.

Detailed Functional Model for Each Operation

Request Fulfillment

• Description: Allows an order manager to request fulfillment of an order
• Pre-Conditions:

1. The client has sufficient information to create the request
2. User or requestor has permissions to create a request within the context

• Conceptual Information Objects
  • Inputs: Order
  • Outputs: Promise

• Post-Conditions:

• Exception Conditions: None identified

• Aspects left for Technical Bindings (optional)

• Reference to Functional Profiles (optional)

• Notes

Communicate Result

• Description: Allows the fulfill to communicate a result to the requestor. This is a conceptual operation representing the "push" of a result from the Fulfiller to the Orderer - at the logical level it would be represented by several operations based on the message exchange pattern.

• Pre-Conditions:

1. A Result (preliminary or final) is available to be communicated to the orderer

• Conceptual Information Objects
  • Inputs: Result
  • Outputs: Code

• Post-Conditions:

1. Result has been communicated and the receipt acknowledged

• Exception Conditions:

• Aspects left for Technical Bindings (optional)

• Reference to Functional Profiles (optional)

• Notes
  • This is a conceptual operation representing the "push" of a result from the Fulfiller to the Orderer - at the logical level it would be represented by several operations based on the message exchange pattern.

Cancel Order

• Description: Used when a requstor (placer) would like for a previously requested, and not yet completed, order to not be performed.

• Pre-Conditions:

1. An order exists and the identifier is known
2. The order is not completed
3. The user or requestor has permission to update an order

• Conceptual Information Objects
  • Inputs: Order, Order Identifier
  • Outputs: Order

• Post-Conditions:

1. The order referenced by order identifier has been cancelled and will not be acted upon.
2. The cancel order identifier is returned

• Exception Conditions:

1. Order is not known to the fulfiller
2. Order has already been completed

Retrieve Result

• Description: Allows a requestor to retrieve a result from the fulfiller with using the result identifier

• Pre-Conditions:

1. The result identifier has been previously communicated to the fulfiller.

• Conceptual Information Objects
  • Inputs: Result Identifier
  • Outputs: Result

• Post-Conditions

• Exception Conditions

• Aspects left for Technical Bindings (optional)

• Reference to Functional Profiles (optional)

• Notes

Profiles

Information Profiles

  Comment
    - describe any information profiles applicable to this service, and the related state transitions