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

Difference between revisions of "Lab AU SB Challenge"

From HL7Wiki
Jump to navigation Jump to search
(New page: 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 b...)
 
Line 19: Line 19:
 
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.
 
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.
 
The diagram below shows the request state machine for the test challenge storyboard.
 +
[[Image:BrokerRequestSM.PNG]]
 
==Storyboard Objects==
 
==Storyboard Objects==
−
From this storyboard and the implied business process, we can derive three objects that the interactions that will occur are concerned about:
+
The broker adds another object to the system:
−
[[Image:Simple_result_objects.PNG]]
 
  
−
There will be a Request object that exists on the Dr Patricia’s care system. It will have an identity of its own, and it will contain some link to the patient Eve, and the list of requested tests. The UML shows these as attributes, but with no details; they are just data place holders that assert that something meeting these functional requirements will exist.
+
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.
 +
[[Image:BrokerObj.PNG]]
  
−
The lab (fulfillment) system will contain one or more result objects, which exist because of the performance of the requested tests and one fulfillment object. Each result has its own identity and knowledge of the request identity, if it exists.  Similarly, the fulfillment object also has an identity of its own.
+
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:
−
Note the differentiation between the fulfillment object and the result object. In almost all implementations of the storyboard, there is a single message or service interaction between systems that combines the two parts:
 
−
*delivery of the actual results that form the fulfillment of the request (result object), and  
 
−
*an assertion that the request is actually filled or fulfillment status (fulfillment object).
 
  
−
Here, we draw these two concepts apart so that the accountability and responsibilities are made explicit for the purposes of analysis. Later, when the actual interaction instances are defined, these different aspects of the interaction may be combined into a single exchange or multiple exchanges based on the requirements.  This is a consistent design pattern that we'll be trying to achieve in this conceptual discussion document; separating out the accountability and responsibilities even if they are recombined later. In addition, we're trying to separate out the cycle of request/fulfillment from the many various result and report patterns that arise during the fulfillment.  
+
[[Image:BrokerSM.PNG]]
  
−
In addition, each of these objects has a status. We can derive the following request object states and transitions from the storyboard:
+
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.
  
−
[[Image:ClinicalRequestLiteSTM.PNG]]
+
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.
  
−
As you can see, the request object has a status for when the fulfiller asserts the request is fulfilled, but the request has not yet evaluated that assertion (called fulfillment resolution).  There are also the two other, expected, request statuses: active and complete.  In the simplest request use cases, the request only takes one of these states.
+
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.  
−
We can derive the following fulfillment object states and transitions from the storyboard:
 
−
 
−
[[Image:FulfillmentLiteSTM.PNG]]
 
  
−
Again the status, this time for fulfillment, is restricted in this simplest use case to null and resulted.
+
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.
−
 
−
Lastly for this simple use case, we can derive the following result object states and transitions from the storyboard:
 
−
 
−
[[Image:ResulttLiteSTM.PNG]]
 
  
−
In this use case, only the completed state is important for interoperability.
+
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#Storyboards and Discussion]]
 
−
 
 
−
 
 
−
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:
 
−
Discussion point: JK’s comment.
 
−
 
−
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.
 

Revision as of 03:58, 22 September 2010

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. BrokerRequestSM.PNG

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.

BrokerObj.PNG

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:

BrokerSM.PNG

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.

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