Lab AU SB Challenge

Back to Conceptual BF Document

Australian Storyboard – Test Challenge

When Dr. Patricia Primary orders a set of tests on Eve Everywoman, her system contacts
a central broker, requesting a test. The broker offers the test to multiple laboratories
that may either accept or reject the test. If they accept the test, they must nominate
a cost. The broker picks the cheapest offer received within a limited time, and returns
that promise to Dr Primary’s system. It cancels the promises received from any other
laboratories.

Dr. Primary prints a paper copy of the request to hand to Eve, where it serves as a
reminder and provides instructions for how to find the correct laboratory collection
center, and perhaps also details some preparation instructions.

Note this storyboard is just a fragment to document a specific process issue.

Business Process

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 diagram below shows the request state machine for the test challenge storyboard.

Storyboard Objects

The broker adds another object to the system:

JK Comment:
With the service specifications, Order Requests cannot be brokered, but fulfillment can be. This was in some respects a
design decision, bu seems to match the obligations of each … the only difference functionally for orderRequestManagement
and fulfillmentManagement is this obligation … that is, that the orderRequestor may identify an interested party who
ultimately wants to access and understand the final status of the order (which may include getting the results report).
The fulfillmentManagement functions simply allow fulfillment to be delegated. 

The broker object mixes these two things up, and so starts to violate separation of concerns. 

That said, it is clear in implementation that you need some set of things to disambiguagte the many to many relationship
between requests and promises …. But these are implementation details, are not necessary (I don’t think) for interoperability,
and mix up the OOD and SAIF separation of concerns that we are trying to get to. 

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