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

Difference between revisions of "Lab JK SB Fulfillment"

From HL7Wiki
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 18: Line 18:
 
|}
 
|}
  
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
+
{| border="1" cellpadding="2"
 +
!width="150"|Initiator
 +
!width="150"|Name
 +
!width="150"|Information
 +
!width="100"|Request State Before
 +
!width="100"|Request State After
 +
!width="100"|Promise State Before
 +
!width="100"|Promise State After
 +
|-
 +
|Placer || Request || Request identity <br> Patient identity <br> Provider identity <br> Test list|| align="center" | Null || align="center" | Searching || align="center" | Null || align="center" | Deciding
 +
|-
 +
|Placer|| Modify || Request identity <br> Patient identity <br> Provider identity <br> New test list || colspan="2" align="center" | ''No change'' || colspan=2 align="center" | ''No Change - either Accept or Reject needed''
 +
|-
 +
|Placer || Suspend || Request identity <br> Patient identity <br> Provider identity <br> Test list|| align="center" | Active || align="center" | Suspended || align="center" | Intent to Fulfill || align="center" | Suspended
 +
|-
 +
|Placer || Release || Request identity <br> Patient identity <br> Provider identity <br> Test list|| align="center" | Suspended || align="center" | Active || align="center" | Suspended || align="center" | Intent to Fulfill
 +
|-
 +
|Placer|| Cancel || Request identity <br> Provider identity <br> Test list <br> Reason for cancelation || colspan="2" align="center" | ''No change'' || colspan=2 align="center" | ''No Change - either Accept or Reject needed''
 +
|-
 +
|Fulfiller || Reject || Request identity <br> Patient identity <br> Reason for rejection || align="center" | Null || align="center" | Rejected || align="center" | Null || align="center" | Rejected
 +
|-
 +
|Fulfiller || Accept || Request identity <br> Patient identity <br> Predicted Delivery Time || align="center" | Seeking || align="center" | Active || align="center" | Deciding || align="center" | Working
 +
|-
 +
|Fulfiller || Accept Modify || Request identity <br> Patient identity || align="center" | Waiting Complete || align="center" | Waiting || align="center" | In Progress - Complete || align="center" | In Progress
 +
|-
 +
|Fulfiller|| Reject Modify || Request identity <br> Patient identity <br> Reason for rejection || colspan="2" align="center" | No change || colspan=2 align="center" | No Change
 +
|-
 +
|Fulfiller || Accept Cancel || Request identity <br> Patient identity || align="center" | Waiting || align="center" | Aborted || align="center" | In Progress || align="center" | Aborted
 +
|-
 +
|Fulfiller|| Reject Cancel || Request identity <br> Patient identity <br> Reason for rejection || colspan="2" align="center" | No change || colspan=2 align="center" | No Change
 +
|-
 +
|Fulfiller || Complete || Request identity <br> Patient identity || align="center" | Waiting || align="center" | Complete || align="center" | Working || align="center" | Complete
 +
|-
 +
|Fulfiller || Failed || Request identity <br> Patient identity <br> Reason for failure || align="center" | Waiting || align="center" | Aborted || align="center" | Working || align="center" | 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
  
 
{| border="1" cellpadding="2"
 
{| border="1" cellpadding="2"
Line 31: Line 69:
 
!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(1)
|-
 
|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|| Refusal || Request identity <br> Patient identity <br> Reason for Refusal || align="center" | Null || align="center" | Refused || align="center" | Request to Fulfill || align="center" | Rejected
+
|Broker|| Query Response || Request info <br> Patient identity || colspan=2 align="center" | No Change || colspan=2 align="center" | No Change
 
|-
 
|-
|Fulfiller|| Complete || Request identity <br> Patient identity || align="center" | Active || align="center" | Complete || align="center" | Request to Fulfill || align="center" | Complete
+
|Broker|| Auction || Request identity <br> Patient identity <br> Provider identity <br> Test list || align="center" | Null || align="center" | Costing || colspan=2 align="center" | No Change
 
|-
 
|-
|Fulfiller|| Failed || Request identity <br> Patient identity <br> Reason for Failure || align="center" | Active || align="center" | Aborted || align="center" | Intent to Fulfill || align="center" | Aborted
+
|Placer|| Bid || Request identity <br> cost || align="center" | Costing || align="center" | Bid || colspan=2 align="center" | Wait for outcome of Auction
 
|}
 
|}
  
 
Back to [[Conceptual BF Document#Additional Requirements]]
 
Back to [[Conceptual BF Document#Additional Requirements]]
  
==Footnotes==
+
==Footnote==
{{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

Latest revision as of 18:31, 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 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
Placer Suspend Request identity
Patient identity
Provider identity
Test list
Active Suspended Intent to Fulfill Suspended
Placer Release Request identity
Patient identity
Provider identity
Test list
Suspended Active Suspended Intent to Fulfill
Placer Cancel Request identity
Provider identity
Test list
Reason for cancelation
No change No Change - either Accept or Reject needed
Fulfiller Reject Request identity
Patient identity
Reason for rejection
Null Rejected Null Rejected
Fulfiller Accept Request identity
Patient identity
Predicted Delivery Time
Seeking Active 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 for rejection
No change No Change
Fulfiller Accept Cancel Request identity
Patient identity
Waiting Aborted In Progress Aborted
Fulfiller Reject Cancel Request identity
Patient identity
Reason for rejection
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 Working 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)
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