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

Lab JK SB Fulfillment

From HL7Wiki
Jump to navigation Jump to search

John K. – Brokered Fulfillment

John's alternate state machine for fulfillment:

FulfillmentJK.PNG

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 Before Request State After Promise State Before Promise State After
Placer Request Request identity
Patient identity
Provider identity
Test list
Null Searching Null Deciding
Placer Modify Request identity
Patient identity
Provider identity
New test list
No change No Change - either Accept or Reject needed


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

Initiator Name Information Request State Before Request State After Promise State Before Promise State After
Fulfiller Query Patient identity
Null Searching No Change(1)
Broker Query Response Request info
Patient identity
No Change No Change
Broker Auction Request identity
Patient identity
Provider identity
Test list
Null Costing No Change
Placer Bid Request identity
cost
Costing Bid Wait for outcome of Auction

Back to Conceptual BF Document#Additional Requirements

Footnote

(1) This transaction doesn’t cause any state transition on the broker; it simply gather all (or some?) of the requests for that patient and returns them. Then the lab can choose to accept them in a separate exchange