This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Order Request Manager Conceptual Specification"

From HL7Wiki
Jump to navigation Jump to search
 
(32 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Link back to [[OO_Behavioral_Model_Conceptual_Specification |solution specification]]
+
Link back to [[Laboratory_Order_Conceptual_Specification |solution specification]]
  
 
==Overview==
 
==Overview==
 
    
 
    
 
===Service Description and Purpose===
 
===Service Description and Purpose===
−
  Comment
+
The purpose of the order request manager is that of a service which provides functionality to manage requests for clinical services and access to the results of their fulfillment.
−
What is the service? Why do we care? Articulation of the Business purpose of the specification Description of the functional capabilities in business terms
 
  
 
===Scope===
 
===Scope===
−
  Comment
+
The Order Manager Service describes the communication patterns between members of a healthcare team that support request and fulfillment, and specifically those pertaining to the management and performance of a request for service(s). This order is considered separately from any process of fulfillment or reporting, except in terms of offering communications to support documentation as an ultimate result of an order request.
−
    Describe the overall potential scope of the service. Are any items being specifically excluded from the scope?  Why?
+
Since these steps are common regardless of clinical service offered, they form a consistent pattern of behavior that may be applied in many situations. In so doing, the Order Manager Service distinguishes between the order for a lab test, the promise of fulfillment, and the lab test itself, which may have a different lifecycle or which may serve a broader audience. More specifically, the Order Manager is explicitly built to provide services for the initiators of the request and fulfillment pattern.
  
  
 
===Reason why the service is necessary===
 
===Reason why the service is necessary===
−
  Comment
+
The Order Manager Service provides a key integration component between systems involved in the distributed practice of patient-centric clinical care. It allows these various systems tied to clinical services to be decoupled from the requests for fulfillment that come from healthcare practitioners. Organizations engaged across organizational boundaries that need to share the business processes around request and fulfillment can benefit from this boundary, as well as more centrally controlled systems within a single jurisdiction. For example, the Order Manager Service enables a lab to operate completely independently from the Order Entry system, and for the clinical process to be managed completely separately from the financial management process that may happen in parallel. Additionally, this separation can happen at an institution or across several institutions or facilities.
−
    Rationale for creating this specification. Consumer viewpoint and the value offered by the work product
+
 
 +
In practice, this separation of concerns provides a clear boundary for the Order Manager's own capabilities. An order is typically accompanied by a set of expectations around the fulfillment of that order; one of which may be that the requester can expect the order management system to reliably capture the status of the eventual fulfillment. The Order Manager Service provides a specification of how this order request can be handled and several different configurations that support different means of systems communicating regarding the status of that request.
 +
 
 +
Note here that this service establishes expectations around the management of the order requests, and hides the details of the fulfillments of that request. Thus, a single order may generate multiple requests for promises of fulfillment, or one, or the Order Manager Service implementation may return a business error (“Request cannot be handled”).
 +
By the same token, fulfillment is managed separately as detailed in the Fulfillment Management (FM) Service. A complicated use case serves to demonstrate the flexibility of separating concerns in this way. A promise of fulfillment may be generated without an initiating order. These services support those sorts of behavioral patterns, but also allow policies to be enforced such that the promise of fulfillment requires an explicit order to be generated. In other words, these services support various policies and means of implementation without unduly binding them all together.
  
−
==Links to Use Cases/ Storyboards==
 
−
* (optional, depending on detail in interop business scenario section
 
 
==Structure of the Service==
 
==Structure of the Service==
−
The Order Request Manager Conceptual Diagram is shown below. Individual functional profiles have not yet been identified as we still need to work through the more complex use cases and identify the need for different profiles to support different contexts.
+
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).  
  
 
[[image:OrderManagementConceptual.png ]]
 
[[image:OrderManagementConceptual.png ]]
  
−
===Organization===
+
===Assumptions and Dependencies===
−
  Comment
+
The Order Manager is a part of an overarching Fulfillment Pattern that describes the contracts that must be implemented by all parties in order to manage the complex business process that underlie Orders and Observations. The Fulfillment Pattern is a choreographed behavioral specification that utilizes these profiles to provide support for key use cases in the Orders and Observations Process provisioned across multiple interfaces. The Fulfillment Pattern has the following components:
−
    Elaborate any logical groupings that emerge from the usage scenarios
+
*The Order Manager Service, with its Order Request State Machine
 +
*At least one Fulfillment Management (FM) Service
 +
*The Fulfillment Behavioral Model, including Fulfillment Pattern’s State Machine
 +
The Order Manager, while deployed separately from these other components, fits within the Fulfillment Behavioral Model as the state of an Order Request may lead to subsequent Fulfillment Behavioral States. In addition, it likely requires the following components in a deployed architecture:
 +
*A unique identification scheme for requestors and trackers. For example, the requestor of an order will require identification for security and auditing concerns, and the order tracker will need a unique address for communication, such as email, application proxy, etc.
 +
*A shared identification scheme for patients about whom orders are written. This shared scheme should be manifest to all clinical service components as well (labs, images, consults, etc.).
 +
*[Optional] A Service Registry would provide authoritative listings of potential types of orders
  
−
===Assumptions and Dependencies===
+
Note however that Order Manager may be deployed without these other components as it effectively provides Order Manager clients with the core ability to manage their requests and to view a condensed view of fulfillment per se. That is often enough.
−
  Comment
+
In short, consumers of the Order Manager will need to have the ability to appropriately form requests and handle responses about them. This interaction with the Order Manager will preclude any explicit knowledge of the fulfillment of the Order itself via the service interface; that is, any knowledge of the fulfillment will happen through other mechanisms (policy, configuration, and so on).
−
    Upon what services does this specification depend (underpinning infrastructure, other HL7 services, etc. Are there any key assumptions that are being made?
 
  
 
===Implementation Considerations===
 
===Implementation Considerations===
−
  Comment
+
None at this time
−
    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==
 
==Detailed Functional Model for Each Operation==
  
−
===Create Request ===
+
===Create Order ===
  
−
*Description: Allows the client to create a request for a service
+
*Description: Allows the client to create an order for a service
  
−
*Pre-Conditions: The client has sufficient information to create the request
+
*Pre-Conditions:  
 +
#The client has sufficient information to create the request
 +
#User or requestor has permissions to create a request within the context
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
 +
**Inputs: Order
 +
**Outputs: Order
  
−
**Inputs: Request
+
*Post-Conditions: The returned order structure has been updated with order identifier 
−
 
 
−
**Outputs: Request Identifier
 
  
−
*Post-Conditions 
+
*Exception Conditions: None identified
−
 
 
−
*Exception Conditions
 
  
 
*Aspects left for Technical Bindings (optional)
 
*Aspects left for Technical Bindings (optional)
Line 59: Line 64:
 
*Notes
 
*Notes
  
−
===Revise Request ===
+
===Change Order ===
 
*Description: Allows the client to submit a change to an existing Order.
 
*Description: Allows the client to submit a change to an existing Order.
  
 
*Pre-Conditions:  
 
*Pre-Conditions:  
−
**An order exists and the identifier is known to the client
+
#An order exists and the identifier is known
−
** The order is currently active
+
#The order is not completed
 +
#The user or requestor has permission to update an order
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
 +
**Inputs: Order, Order Identifier
 +
**Outputs: Order, Promise
  
−
**Inputs: Request, Request Identifier
+
*Post-Conditions:  
 +
#The order referenced by order identifier has been updated to match the requirements in the input order
 +
#The modified order is returned
  
−
**Outputs: Identifier
+
*Exception Conditions:
−
 
+
#Order is not known to the fulfiller
−
*Post-Conditions 
+
#Order has already been completed
−
 
 
−
*Exception Conditions
 
  
 
*Aspects left for Technical Bindings (optional)
 
*Aspects left for Technical Bindings (optional)
Line 82: Line 90:
 
*Notes
 
*Notes
  
−
===Cancel Request ===
+
===Cancel Order===
−
*Description:  
+
*Description: Used when a requestor (placer) would like for a previously requested, and not yet completed, order to not be performed.
  
 
*Pre-Conditions:  
 
*Pre-Conditions:  
 +
#An order exists and the identifier is known
 +
#The order is not completed
 +
#The user or requestor has permission to update an order
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
 +
**Inputs: Order, Order Identifier
 +
**Outputs: Order
  
−
**Inputs:  
+
*Post-Conditions:  
 +
#The order referenced by order identifier has been cancelled and will not be acted upon.
 +
#The cancel order is returned
  
−
**Outputs:  
+
*Exception Conditions:
 +
#Order is not known to the fulfiller
 +
#Order has already been completed
  
−
*Post-Conditions 
+
===Query Orders===
−
 
+
*Description: Used to obtain a list of Orders relevant to a specific Subject.
−
*Exception Conditions
 
−
 
 
−
*Aspects left for Technical Bindings (optional)
 
−
 
 
−
*Reference to Functional Profiles (optional)
 
−
 
 
−
*Notes
 
−
 
 
−
===Query Request ===
 
−
*Description:  
 
  
 
*Pre-Conditions:  
 
*Pre-Conditions:  
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
−
 
+
**Inputs: Subject
−
**Inputs:  
+
**Outputs: a list of Orders
−
 
 
−
**Outputs:  
 
  
 
*Post-Conditions   
 
*Post-Conditions   
Line 122: Line 127:
 
*Reference to Functional Profiles (optional)
 
*Reference to Functional Profiles (optional)
  
−
*Notes
+
*Notes:
 +
** At the logical level, addition query criteria (eg date ranges, result status, etc) may be defined
  
−
===Retrieve Result ===
+
===Retrieve Order ===
−
*Description:  
+
*Description: Allows the client to retrieve a specific Order, given an order identifier
  
 
*Pre-Conditions:  
 
*Pre-Conditions:  
 +
# The order identifier is known
 +
# The client has permission to retrieve orders
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
−
 
+
**Inputs: Order Identifier
−
**Inputs:  
+
**Outputs: Order
−
 
 
−
**Outputs:  
 
  
 
*Post-Conditions   
 
*Post-Conditions   
Line 145: Line 151:
 
*Notes
 
*Notes
  
−
===Update Request Status ===
+
===Update Order Status ===
  
−
*Description: Allows the client to identify a change in status of the request
+
*Description: Allows the client to identify a change in status of the order (e.g. update the status to 'specimen collected')
  
 
*Pre-Conditions:  
 
*Pre-Conditions:  
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
 +
**Inputs: Order Identifier, Status
 +
**Outputs: Order
  
−
**Inputs: Request Identifier, Status
+
*Post-Conditions: The order status has been changed to the new value
−
 
 
−
**Outputs: Request
 
  
−
*Post-Conditions: The request status has been changed to the new value
+
*Exception Conditions: The order identifier cannot be found.<br> The status change request is an invalid state transition
−
 
 
−
*Exception Conditions: The request identifier cannot be found.<br> The status change request is an invalid state transition
 
  
 
*Aspects left for Technical Bindings (optional)
 
*Aspects left for Technical Bindings (optional)
Line 166: Line 170:
  
 
*Notes
 
*Notes
−
 
  
 
===Update Result Status ===
 
===Update Result Status ===
−
*Description:  
+
*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:  
 
*Pre-Conditions:  
 +
# Result must already exist
  
 
*Conceptual Information Objects
 
*Conceptual Information Objects
−
 
+
**Inputs: Result, Result Identifier
−
**Inputs:  
+
**Outputs: Result
−
 
 
−
**Outputs:  
 
  
 
*Post-Conditions   
 
*Post-Conditions   
 +
# Result updated with new status
  
−
*Exception Conditions
+
*Exception Conditions: Order does not previously exist
  
 
*Aspects left for Technical Bindings (optional)
 
*Aspects left for Technical Bindings (optional)
Line 190: Line 193:
  
 
==Profiles==
 
==Profiles==
 +
TBD
 +
 
===Introduction===
 
===Introduction===
  
Line 196: Line 201:
 
===Information Profiles===
 
===Information Profiles===
  
−
  Comment
+
=Recommendations for Conformance and Compliance=
−
    - 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

Latest revision as of 00:39, 27 November 2012

Link back to solution specification

Overview

Service Description and Purpose

The purpose of the order request manager is that of a service which provides functionality to manage requests for clinical services and access to the results of their fulfillment.

Scope

The Order Manager Service describes the communication patterns between members of a healthcare team that support request and fulfillment, and specifically those pertaining to the management and performance of a request for service(s). This order is considered separately from any process of fulfillment or reporting, except in terms of offering communications to support documentation as an ultimate result of an order request. Since these steps are common regardless of clinical service offered, they form a consistent pattern of behavior that may be applied in many situations. In so doing, the Order Manager Service distinguishes between the order for a lab test, the promise of fulfillment, and the lab test itself, which may have a different lifecycle or which may serve a broader audience. More specifically, the Order Manager is explicitly built to provide services for the initiators of the request and fulfillment pattern.


Reason why the service is necessary

The Order Manager Service provides a key integration component between systems involved in the distributed practice of patient-centric clinical care. It allows these various systems tied to clinical services to be decoupled from the requests for fulfillment that come from healthcare practitioners. Organizations engaged across organizational boundaries that need to share the business processes around request and fulfillment can benefit from this boundary, as well as more centrally controlled systems within a single jurisdiction. For example, the Order Manager Service enables a lab to operate completely independently from the Order Entry system, and for the clinical process to be managed completely separately from the financial management process that may happen in parallel. Additionally, this separation can happen at an institution or across several institutions or facilities.

In practice, this separation of concerns provides a clear boundary for the Order Manager's own capabilities. An order is typically accompanied by a set of expectations around the fulfillment of that order; one of which may be that the requester can expect the order management system to reliably capture the status of the eventual fulfillment. The Order Manager Service provides a specification of how this order request can be handled and several different configurations that support different means of systems communicating regarding the status of that request.

Note here that this service establishes expectations around the management of the order requests, and hides the details of the fulfillments of that request. Thus, a single order may generate multiple requests for promises of fulfillment, or one, or the Order Manager Service implementation may return a business error (“Request cannot be handled”). By the same token, fulfillment is managed separately as detailed in the Fulfillment Management (FM) Service. A complicated use case serves to demonstrate the flexibility of separating concerns in this way. A promise of fulfillment may be generated without an initiating order. These services support those sorts of behavioral patterns, but also allow policies to be enforced such that the promise of fulfillment requires an explicit order to be generated. In other words, these services support various policies and means of implementation without unduly binding them all together.

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

Assumptions and Dependencies

The Order Manager is a part of an overarching Fulfillment Pattern that describes the contracts that must be implemented by all parties in order to manage the complex business process that underlie Orders and Observations. The Fulfillment Pattern is a choreographed behavioral specification that utilizes these profiles to provide support for key use cases in the Orders and Observations Process provisioned across multiple interfaces. The Fulfillment Pattern has the following components:

  • The Order Manager Service, with its Order Request State Machine
  • At least one Fulfillment Management (FM) Service
  • The Fulfillment Behavioral Model, including Fulfillment Pattern’s State Machine

The Order Manager, while deployed separately from these other components, fits within the Fulfillment Behavioral Model as the state of an Order Request may lead to subsequent Fulfillment Behavioral States. In addition, it likely requires the following components in a deployed architecture:

  • A unique identification scheme for requestors and trackers. For example, the requestor of an order will require identification for security and auditing concerns, and the order tracker will need a unique address for communication, such as email, application proxy, etc.
  • A shared identification scheme for patients about whom orders are written. This shared scheme should be manifest to all clinical service components as well (labs, images, consults, etc.).
  • [Optional] A Service Registry would provide authoritative listings of potential types of orders

Note however that Order Manager may be deployed without these other components as it effectively provides Order Manager clients with the core ability to manage their requests and to view a condensed view of fulfillment per se. That is often enough. In short, consumers of the Order Manager will need to have the ability to appropriately form requests and handle responses about them. This interaction with the Order Manager will preclude any explicit knowledge of the fulfillment of the Order itself via the service interface; that is, any knowledge of the fulfillment will happen through other mechanisms (policy, configuration, and so on).

Implementation Considerations

None at this time

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

TBD

Introduction

Functional Profiles

Information Profiles

Recommendations for Conformance and Compliance

These will be elaborated in the next round of specification development

Retrieved from "https://wiki.hl7.org/w/index.php?title=Order_Request_Manager_Conceptual_Specification&oldid=68044"