This wiki has undergone a migration to Confluence found Here

Order Request Manager Conceptual Specification

From HL7Wiki
Jump to navigation Jump to search

Link back to solution specification

Overview

Service Description and Purpose

The purpose of the order request manager is that of a service which can analyze the results returned from the fulfiller and determine when the request has been fulfilled from an ordering perspective.

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 Order Manager Conceptual Diagram is shown below. A separate functional profile is defined for organizations that need only specimen collection operations (for instance, third party specimen collectors).

OrderManagementConceptual.png

Organization

 Comment
   Elaborate any logical groupings that emerge from the usage scenarios

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

Create Order

  • Description: Allows the client to create an order for a service
  • 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: Order
  • Post-Conditions: The returned order structure has been updated with order identifier
  • Exception Conditions: None identified
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes

Change Order

  • Description: Allows the client to submit a change to an existing Order.
  • 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, Promise
  • Post-Conditions:
  1. The order referenced by order identifier has been updated to match the requirements in the input order
  2. The modified order is returned
  • Exception Conditions:
  1. Order is not known to the fulfiller
  2. Order has already been completed
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes

Cancel Order

  • Description: Used when a requestor (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 is returned
  • Exception Conditions:
  1. Order is not known to the fulfiller
  2. Order has already been completed

Query Orders

  • Description: Used to obtain a list of Orders relevant to a specific Subject.
  • Pre-Conditions:
  • Conceptual Information Objects
    • Inputs: Subject
    • Outputs: a list of Orders
  • Post-Conditions
  • Exception Conditions
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes:
    • At the logical level, addition query criteria (eg date ranges, result status, etc) may be defined

Retrieve Order

  • Description: Allows the client to retrieve a specific Order, given an order identifier
  • Pre-Conditions:
  1. The order identifier is known
  2. The client has permission to retrieve orders
  • Conceptual Information Objects
    • Inputs: Order Identifier
    • Outputs: Order
  • Post-Conditions
  • Exception Conditions
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes

Update Order Status

  • Description: Allows the client to identify a change in status of the order (e.g. update the status to 'specimen collected')
  • Pre-Conditions:
  • Conceptual Information Objects
    • Inputs: Order Identifier, Status
    • Outputs: Order
  • Post-Conditions: The order status has been changed to the new value
  • Exception Conditions: The order identifier cannot be found.
    The status change request is an invalid state transition
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes

Update Result Status

  • Description: Allows the fulfiller (or performer) of the order (whom is also the author of the result) to change the status of the result.
  • Pre-Conditions:
  1. Result must already exist
  • Conceptual Information Objects
    • Inputs: Result, Result Identifier
    • Outputs: Result
  • Post-Conditions
  1. Result updated with new status
  • Exception Conditions: Order does not previously exist
  • Aspects left for Technical Bindings (optional)
  • Reference to Functional Profiles (optional)
  • Notes

Profiles

Introduction

Functional Profiles

Information Profiles

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

Recommendations for Conformance and Compliance

These will be elaborated in the next round of specification development