Lab JK SB Fulfillment

John K. – Brokered Fulfillment

John's alternate state machine for fulfillment:

Business Process

The broker object gets its own set of suspend and cancel related states as well (not shown). From these state transitions, we can derive a new set of roles and exchanges. Roles: Placer Places the original request, and waits for it to be complete. May have an order manager Broker Chooses a lab, or holds the request until the patient chooses a lab. May mediate communications subsequently Fulfiller Accepts the request, and then carries out the activities to fulfill what was asked

Initiator Name Information Request State Transitions Promise State Transition Before After Before After Placer Request Request identity Patient identity Clinician Identity Test list Initial Seeking Initial Deciding Placer Modify Request identity Patient Identity New Test list No change No Change – either Accept or Reject needed Placer Suspend Request identity Patient Identity Waiting Suspended In Progress Suspended Placer Unsuspend Request identity Patient Identity Suspended Waiting Suspended In Progress Placer Cancel Request Identity Patient Identity Reason No change No Change – either Accept or Reject needed Fulfiller Refusal Request Identity Patient Identity Reason for Refusal Seeking Refused Deciding Rejected Fulfiller Accept Request Identity Patient Identity Predicted Delivery Time? Seeking Waiting Deciding Working Fulfiller Accept Modify Request Identity Patient Identity Waiting | Complete Waiting In Progress | Complete In Progress Fulfiller Reject Modify Request Identity Patient Identity Reason No Change No Change Fulfiller Accept Cancel Request Identity Patient Identity Waiting Canceled In Progress Canceled Fulfiller Reject Cancel Request Identity Patient Identity Reason No Change No Change Fulfiller Complete Request Identity Patient Identity Waiting Complete Working Complete Fulfiller Failed Request Identity Patient Identity Reason for Failure Waiting Aborted Waiting Failed

The broker plays the roles of both placer and fulfiller. It has the same exchanges, though the state transitions and the consequential workflow differ. However there are few broker specific exchanges. In the mode where the broker holds the request waiting for a patient to attend a laboratory, we need an exchange to allow the laboratory to find any outstanding requests for that patient. For the broker mode where the broker holds an auction for the request, we could implement it using the exchanges described above, but that leads to an odd workflow. Given the exchanges above, when the broker receives a request, it would hand the request on to all participants of the auction, who would all then ‘accept’ the request. The broker would pick the best offer, and cancel all the others. Perhaps the others may refuse to cancel, but that would be pretty pointless. This is possible, but it doesn’t really match what’s going on, and it’s going to at least cause confusion for the implementers. So it’s better to define specific exchanges. Initiator Name Information Promise State Transitions Broker State Transition Before After Before After Fulfiller Query Patient identity Initial Searching No Change Broker Query Response Patient identity (Request Info)n No Change No Change Broker Auction Request identity Patient identity Clinician Identity Test list Initial Costing No Change Placer Bid Request identity Cost Costing Bid Wait for outcome of Auction Order brokers can also be known as clearing houses or order registries (or other names), and are growing in popularity, though there are also controversial aspects to their existence and operation. If we are going to have a standard that relates to laboratory orders, then it should allow the use of brokers without being too intrusive.

The Broker object doesn’t have a particular identity – we’re not interested in it as an entity in its own right (though of course the broker itself will have an identifier for the actual object it uses internally). But we do think of the status of the broker, and it does have a state machine that is of interest externally:

This is a more complicated state machine because it’s more dependent on the process that the broker is involved in, and because it is inserted between the placer and the fulfiller. The first dependency is the choice point for whether the broker is acting as an auction house, or just holding the request.

If the broker is just acting to hold the request, it will hold the request until a lab contacts it for details when Eve actually turns up at the lab, at which time it will send the fulfillers promise to the placer. Under some circumstances, it will decide that it has held the request for too long, and time it out if Eve does not attend the lab within a specified time period. Whether this happens depends on business arrangements; for instance, there may be a legal requirement that the request is only legal for a limited period. This also applies to the lab system too, though this was not accounted for above.

If the broker is acting as an auction house, it will conduct an auction by sending the request on two some registered list of lab systems. Once they have all responded, or some specified time period has been exceeded, or some other business decision is made, the broker can either decide that no lab is willing or able to provide the service, and it has failed, or it will pick a lab and return the promise.

What happens next depends on whether the broker is mediating communications between the lab that is acting as a fulfiller and the placer. This choice is purely dictated by implementation details, whether it is practical for the placer and the fulfiller to communicate directly. If they do communicate directly, the broker’s involvement is complete, otherwise the broker status tracks the fulfiller status.

The Broker acts as a façade for the fulfiller; in principle, the placer has the same exchanges with the broker as with a fulfiller, though the timing of the interactions could be very different, along with the technical communications architecture.

Back to Conceptual BF Document#Additional Requirements