This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Lab JK SB Fulfillment"

From HL7Wiki
Jump to navigation Jump to search
Line 31: Line 31:
 
!width="100"|Promise State After
 
!width="100"|Promise State After
 
|-
 
|-
|Fulfiller || Query || Patient identity <br>|| align="center" | Null || align="center" | Searching || colspan=2 align="center" | No Change <ref>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</ref>
+
|Fulfiller || Query || Patient identity <br>|| align="center" | Null || align="center" | Searching || colspan=2 align="center" | No Change<ref>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</ref>
 
|-
 
|-
 
|Fulfiller|| Accept || Request identity <br> Patient identity <br> Predicted Delivery <br> time? || align="center" | Null || align="center" | Promised || align="center" | Request to Fulfill || align="center" | Intent to Collect <br> or <br> Intent to Fulfill
 
|Fulfiller|| Accept || Request identity <br> Patient identity <br> Predicted Delivery <br> time? || align="center" | Null || align="center" | Promised || align="center" | Request to Fulfill || align="center" | Intent to Collect <br> or <br> Intent to Fulfill
Line 45: Line 45:
  
 
==Footnotes==
 
==Footnotes==
{{reflist}}
+
{{Reflist}}

Revision as of 06:14, 22 September 2010

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 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

Initiator Name Information Request State Before Request State After Promise State Before Promise State After
Fulfiller Query Patient identity
Null Searching No Change[1]
Fulfiller Accept Request identity
Patient identity
Predicted Delivery
time?
Null Promised Request to Fulfill Intent to Collect
or
Intent to Fulfill
Fulfiller Refusal Request identity
Patient identity
Reason for Refusal
Null Refused Request to Fulfill Rejected
Fulfiller Complete Request identity
Patient identity
Active Complete Request to Fulfill Complete
Fulfiller Failed Request identity
Patient identity
Reason for Failure
Active Aborted Intent to Fulfill Aborted

Back to Conceptual BF Document#Additional Requirements

Footnotes

Template:Reflist

  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