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

Difference between revisions of "Conceptual BF Document"

From HL7Wiki
Jump to navigation Jump to search
 
(50 intermediate revisions by 4 users not shown)
Line 2: Line 2:
  
 
=Laboratory Ordering and Fulfillment=
 
=Laboratory Ordering and Fulfillment=
The Architecture Review Board (ArB) in conjunction with the Orders & Observations Work Group selected the Laboratory Domain to challenge the new SAIF Behavioral Framework and methodology.  OO and the former Lab SIG/WG were stuck for years in balloting by a negative vote which Lab itself was unable to solve (and therefore, Lab eventually withdrew the Lab Order topic ever since).  That negative was in it's basis a negative-major comment regarding the lack of the current dynamic model and balloted artifacts to sufficiently communicate the Laboratory Ordering interoperability behaviors.
+
The Architecture Review Board (ArB) in conjunction with the Orders & Observations Work Group selected the Laboratory Domain to challenge the new SAIF Behavioral Framework and methodology.  OO and the former Lab SIG/WG were stuck for years in balloting by a negative vote which Lab itself was unable to solve (and therefore, Lab eventually withdrew the Lab Order topic).  That negative had at it's basis a negative-major comment regarding the lack of a current dynamic model and balloted artifacts to sufficiently communicate the Laboratory Ordering interoperability behaviors.
  
 
==Document Status==
 
==Document Status==
Line 20: Line 20:
 
* Behavioral Framework (BF)
 
* Behavioral Framework (BF)
 
* Information Framework (IF)
 
* Information Framework (IF)
 
  
 
The Behavioral Framework includes a behavioral model which documents the ‘actions’ during the exchange of information between systems.  In the current HL7 methodology, this is referred to as the dynamic model.   
 
The Behavioral Framework includes a behavioral model which documents the ‘actions’ during the exchange of information between systems.  In the current HL7 methodology, this is referred to as the dynamic model.   
Line 31: Line 30:
  
 
Following each storyboard narrative is a breakdown of the represented business process, objects for exchange, and the state or status of each object if appropriate.  From these data points, requirements will be abstracted and documented.
 
Following each storyboard narrative is a breakdown of the represented business process, objects for exchange, and the state or status of each object if appropriate.  From these data points, requirements will be abstracted and documented.
 +
 +
==Business Scenarios==
 +
Below follows business scenarios and processes with discussion immediately after each to highlight relevant points from that particular scenario or process.
 +
*[[Lab Business Process Storyboard]]
 +
 
==Storyboards and Discussion==
 
==Storyboards and Discussion==
 
Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases.
 
Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases.
 
*[[Lab UV SB Simple|Universal Storyboard – Simple]]
 
*[[Lab UV SB Simple|Universal Storyboard – Simple]]
 
*[[Lab UV SB Revise|Universal Storyboard – Revise, Hold, Abort]]
 
*[[Lab UV SB Revise|Universal Storyboard – Revise, Hold, Abort]]
 +
*[[Lab UV SB Problem|Universal Storyboard - Specimen Problems]]
 
*[[Lab AU SB Report|Australian Storyboard – Promise, Result Report]]
 
*[[Lab AU SB Report|Australian Storyboard – Promise, Result Report]]
 +
*[[Lab UV SB Verify|Universal Storyboard - Result Verification]]
 +
*[[Lab UV SB Interpret|Universal Storyboard - Result Interpretation]]
 
*[[Lab UV SB Micro Correct|Universal Storyboard – Microbiology Result Report, Corrected Result]]
 
*[[Lab UV SB Micro Correct|Universal Storyboard – Microbiology Result Report, Corrected Result]]
 
*[[Lab AU SB Withdraw|Australian Storyboard – Withdraw Report]]
 
*[[Lab AU SB Withdraw|Australian Storyboard – Withdraw Report]]
 
*[[Lab UV SB Document|Universal Storyboard – ReportDocument Events]]
 
*[[Lab UV SB Document|Universal Storyboard – ReportDocument Events]]
 +
*[[Lab PH Field Collect|Public Health Storyboard – Field Specimen Collection]]
  
 
==Roles and Interactions==  
 
==Roles and Interactions==  
All of the initial use cases can be broken down into individual interactions, each between a sender and an intended receiver (who is also the fulfiller). As such, we can derive a set of roles and exchanges from the object state machines, and use this information to build a set of business services.  
+
The initial use cases can be broken down into interactions between a sender and an intended receiver (who is also the fulfiller). In terms of the Behavioral Framework, these are the Commissioning Party and the Responsible Party. Based on the role and accountability / obligation we can derive a set of business services that realize the required behaviors and manage the appropriate state transitions.  These services can be composed into interactions and interoperability scenarios and implemented by a variety of exchange patterns (request/response, publish/subscribe, synchronous or asynchronous messages, etc).
 +
 
 +
  LC Comment:
 +
  Working on recasting this into the language of the Behavioral Framework. Commissioning Party, Responsible Party, Obligations, Operations, Information Exchange, Exceptions.
 +
  I will leave comments to indicate where I am in progress, then remove them as I work through it.
  
 
The first thing is to identify the roles. So far, we have:
 
The first thing is to identify the roles. So far, we have:
Line 48: Line 60:
 
!width="200"|Role
 
!width="200"|Role
 
!width="600"|Description
 
!width="600"|Description
 +
!width="200"|BF Mapping
 
|-
 
|-
|Order Requestor (Placer in v2) || Places the original request, and waits for it to be completed
+
|Order Requestor (Placer in v2) || Places the original request, and waits for it to be completed || Commissioning Party
 
|-
 
|-
|Request Fulfiller) || Accepts the request, and then carries out the activities to fulfill what was asked
+
|Request Fulfiller) || Accepts the request, and then carries out the activities to fulfill what was asked || Responsible Party
 
|-
 
|-
|Fulfillment Manager || Monitors the Order Requestor as it receives activities which fulfill the original request and determines when the fulfillment activities ‘complete’ the request
+
|Fulfillment Manager || Monitors the Order Requestor as it receives activities which fulfill the original request and determines when the fulfillment activities ‘complete’ the request || May be the commissioning or the responsible party at different stages of the business process flow
 
|-
 
|-
 
|}
 
|}
  
 +
LC Comment:
 +
  As we work through the use cases identifying operations with related information objects, this next table should be transformed into one with headings
 +
  Commissioning System Role || Required Interface || Responsible System Role || Responsible Agent / Service Interface || Operation
 +
 
 +
  The operations each then wrap the information payloads, carry out specific obligations and effect the state transitions, and may eventually define exceptions.
 +
  If we think this is the correct path, the next suggested step is to attempt a UML computational model based on the use cases, then revisit this table.
  
 
The state transitions in the request and promise class are linked by exchanges between the systems that play the two roles. They can be presented in a tabular form:
 
The state transitions in the request and promise class are linked by exchanges between the systems that play the two roles. They can be presented in a tabular form:
 
{| border="1" cellpadding="2"
 
{| border="1" cellpadding="2"
 
!width="150"|Initiator
 
!width="150"|Initiator
!width="150"|Name
+
!width="150"|Exchange Name
!width="200"|Information
+
!width="150"|Information
 
!width="100"|Request State Before
 
!width="100"|Request State Before
 
!width="100"|Request State After
 
!width="100"|Request State After
Line 68: Line 87:
 
!width="100"|Promise State After
 
!width="100"|Promise State After
 
|-
 
|-
|Order Requestor || Request || Request identity Patient identity Provider identity Test list || align="center" | Null || align="center" | Active || align="center" | Null || align="center" | Request to Fulfill
+
|Order Requestor || Request || Request identity <br> Patient identity <br> Provider identity <br> Test list || align="center" | Null || align="center" | Active || align="center" | Null || align="center" | Request 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
 +
|-
 +
|Fulfiller|| Refuse || Request identity <br> Patient identity <br> Reason for Refusal || align="center" | Null || align="center" | Refused || align="center" | Request to Fulfill || align="center" | Rejected
 
|-
 
|-
|Fulfiller|| Refusal || Request identity Patient identity Reason for Refusal || align="center" | Null || align="center" | Refused || align="center" | Request to Fulfill || align="center" | Rejected
+
|Fulfiller|| Complete || Request identity <br> Patient identity || align="center" | Active || align="center" | Complete || align="center" | Request to Fulfill || align="center" | Complete
 
|-
 
|-
|Composite Order Template || POOR_RM200999UV || align="center" | R1 || align="center" | MAY 09 || align="center" | M2 || align="center" | [http://www.hl7.org/documentcenter/ballots/2008JAN/reconciliation/recon_v3_or_compord_r1_m1_2008jan.xls]
+
|Fulfiller|| Fail || Request identity <br> Patient identity <br> Reason for Failure || align="center" | Active || align="center" | Aborted || align="center" | Intent to Fulfill || align="center" | Aborted
 
|}
 
|}
 
OrderRequestor Request Request identity
 
Patient identity
 
Clinician Identity
 
Test list Initial Active Initial Request to Fulfill
 
Fulfiller Refusal Request Identity
 
Patient Identity
 
Reason for Refusal Initial Refused Request to Fulfill Rejected
 
Fulfiller Accept Request Identity
 
Patient Identity
 
Predicted Delivery Time? Initial Promised Request to Fulfill Intent to Collect or Intent to Fulfill
 
Fulfiller Complete Request Identity
 
Patient Identity Active Complete Intent to Fulfill Complete
 
Fulfiller Failed Request Identity
 
Patient Identity
 
Reason for Failure Active Aborted Intent to Fulfill Aborted
 
  
 
These interactions can be assembled into services using either request/response, publish/subscribe, or implemented using synchronous or asynchronous messages. But whatever the architecture, these are the essential information exchanges that need to occur.
 
These interactions can be assembled into services using either request/response, publish/subscribe, or implemented using synchronous or asynchronous messages. But whatever the architecture, these are the essential information exchanges that need to occur.
Line 98: Line 105:
 
Other obligations might be to validate that the request is valid, or to inform other systems, or to perform some further business processing. These obligations are out of scope when building an interoperability standard, as are the obligations on the placer such as ensuring that the order is one it is allowed to submit.
 
Other obligations might be to validate that the request is valid, or to inform other systems, or to perform some further business processing. These obligations are out of scope when building an interoperability standard, as are the obligations on the placer such as ensuring that the order is one it is allowed to submit.
  
 +
==Additional Requirements==
 
However, this is not all there is to lab orders. There are several key additional requirements that need to be provided for.  
 
However, this is not all there is to lab orders. There are several key additional requirements that need to be provided for.  
 
   
 
   
Order Brokers
+
===Order Brokers===
Canadian Storyboard – Jurisdictional Lab Information System
+
*[[Lab CA SB JLIS|Canadian Storyboard – Regional Repository]]
Dr. Patricia Primary orders a set of tests on Eve Everywoman.  Dr. Primary’s care system sends the order to the local-area lab repository.  Dr. Primary’s care system prints a paper copy of the order requisition that tells her where she can have specimens collected and the testing performed.  Eve can attend any laboratory to have the tests done – whichever one she chooses.
+
*[[Lab AU SB Challenge|Australian Storyboard – Test Challenge]]
When Eve actually presents at the laboratory of her choice, the laboratory system connects to the central broker and retrieves the order. The lab information informs the central broker that it is performing the tests (promise).  The broker system sends the performing lab information to Dr Primary’s care system.
+
*[[Lab AU SB Follow|Australian Storyboard – Follow-up Testing/Revise Order]]
Note this storyboard is just a fragment to document a specific process issue.
+
*[[Lab JK SB Fulfillment|John K. - Brokered Fulfillment]]
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
+
===Order Manager===
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.
 
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.
 
Australian Storyboard - Follow-up Testing (Revise Order)
 
One week after the initial consultation, Eve is again seen by Dr Patricia. After review of the results and the course of Eve’s condition, Dr Patricia decides that another lab test would be useful. Rather than asking Eve to go to the collection center again, Dr Patricia types the test into her system as a follow up test. Dr Patricia’s care system sends this request to the lab system, which replies, promising to perform this new test and whether the remaining volume of the current specimen is sufficient to complete the follow-up test(s).
 
Note this storyboard is just a fragment to document a specific process issue.
 
You could simply say that this is a new request, with a new promise. But in Australia there are legal requirements in many jurisdictions about this, and some specify that such follow up testing is logically done as a modification of the previous request. In these circumstances, it is much simpler to treat the follow up test as changing the status of the original test and adding new order components. And this can happen at any time, even after the request has been completed.
 
 
This adds two state transitions to the request object, and there are similar additions to the promise state machine.
 
Order Manager
 
 
The most common end state for the request cycle is that the laboratory or fulfiller claims that request has been completed. An important question is whether the placer agrees that whatever was requested has actually been performed. There are several reasons why the placer may not agree:
 
The most common end state for the request cycle is that the laboratory or fulfiller claims that request has been completed. An important question is whether the placer agrees that whatever was requested has actually been performed. There are several reasons why the placer may not agree:
Clerical error The whole point of this request cycle is that there should be no capacity for clerical error
+
 
Configuration Error The mapping between the request code and the lab system test code may be in error
+
{| border="1" cellpadding="2"
Clinical Interpretation The lab applies clinical judgment when deciding what to do; there may be disagreement between the clinician and the lab in this area.
+
|-
 +
|width="200"|Clerical Error || width="600"|The whole point of this request cycle is that there should be no capacity for clerical error
 +
|-
 +
|Configuration Error || The mapping between the request code and the lab system test code may be in error
 +
|-
 +
|Clinical Interpretation || The lab applies clinical judgment when deciding what to do; there may be disagreement between the clinician and the lab in this area.
 +
|-
 +
|}
 
For this reason, many clinical systems that place lab requests provide functionality to check what was performed against what was requested; this is known as an “Order Manager”. It also tracks the requests so that some clinical user can be alerted in the case that requests are not progressing or completed – for instance, if the patient does not attend any lab to have their specimen(s) collected.   
 
For this reason, many clinical systems that place lab requests provide functionality to check what was performed against what was requested; this is known as an “Order Manager”. It also tracks the requests so that some clinical user can be alerted in the case that requests are not progressing or completed – for instance, if the patient does not attend any lab to have their specimen(s) collected.   
 +
 +
PEL Comment:
 +
Order managers also typically manage what are called “Parent” or “Recurring” orders. Order manager functionality may be part of
 +
the placer system, filler system, or an independent system. An order manager can take a parent order, explode it into occurrence
 +
(aka. Child orders) which are then sent to the filler system. An order manager may also take a “composite order, explode it into
 +
individual orders and forward them onto the appropriate departmental filler system. This is the idea behind our V3 Composite order.
 +
 +
AJK: An example of exploding a composite order, consider a composite order containing both an Rx order for warfarin and a recurring lab order for PT/INR. The order manager would explode the composite order into the drug order, which is forwarded to the pharmacy application, and the lab order, which may be exploded into a series of occurrence orders that are sent to the lab application at the appropriate time.
 +
 
In order for the Order Manager to function, it must be able to track the laboratory reports and compare the list of reports received, along with their status and contents, against its own expected list. To enable the Order Manager to track the reports, all the reports that the lab sends to the placing system must identify the request(s) that the report is considered to be fulfilling.  As discussed above, this may occur even after the request/promise cycle is complete.
 
In order for the Order Manager to function, it must be able to track the laboratory reports and compare the list of reports received, along with their status and contents, against its own expected list. To enable the Order Manager to track the reports, all the reports that the lab sends to the placing system must identify the request(s) that the report is considered to be fulfilling.  As discussed above, this may occur even after the request/promise cycle is complete.
 +
 
When the order manager detects an issue, it must notify a human. There are no request or promise state transitions related to the order manager. However there is an exchange related to the order manager: the order manager may inform the laboratory that it has detected an issue as well as informing its own users through some process that is out of scope for this analysis. In order to treat this consistently, we can define an order manager object, along with a laboratory equivalent.
 
When the order manager detects an issue, it must notify a human. There are no request or promise state transitions related to the order manager. However there is an exchange related to the order manager: the order manager may inform the laboratory that it has detected an issue as well as informing its own users through some process that is out of scope for this analysis. In order to treat this consistently, we can define an order manager object, along with a laboratory equivalent.
 +
 +
[[Image:TrackerObj.PNG]]
 
   
 
   
 
Again, these objects do not have an explicit identity of their own that we interested in, and they do not need to directly exist in that form – all this is saying that from an external perspective, the systems behave as if these objects exist.
 
Again, these objects do not have an explicit identity of their own that we interested in, and they do not need to directly exist in that form – all this is saying that from an external perspective, the systems behave as if these objects exist.
 +
 +
[[Image:TrackerSM.PNG]]
 
   
 
   
 
These are very simple state transition diagrams. There are many other potential states related to the interaction of the logical trackers with humans (review, mark-off, etc), but these are not relevant to the request/promise cycle.
 
These are very simple state transition diagrams. There are many other potential states related to the interaction of the logical trackers with humans (review, mark-off, etc), but these are not relevant to the request/promise cycle.
<???> do we need the storyboard where lab A can’t do all the tests, so the specimen is split and lab B does some of the testing.  Sometimes, lab B reports back to the original orderer, other times lab B reports to Lab A; who compiles all reports and communicated
+
 
<???> add Austin’s public health storyboard?  Namely CDC requests specimen, local lab system ‘places’ order – public health entity is the fulfiller.
+
==Putting it all together==
<???> Standing order tracking fulfillment story board
 
<???> other pending order (np orders, md student orders) which require supervision
 
<???> order authorization?
 
<???> what other storyboards do we need to fill out the requirements for lab fulfillment?
 
Putting it all together
 
 
Taking all these extra factors gives us final state transitions for request and promise that look like this:
 
Taking all these extra factors gives us final state transitions for request and promise that look like this:
 
 
John's alternate state machine for fulfillment:
 
 
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
+
[[Image:RequestFinal.PNG]]
Before After Before After
+
 
Placer Request Request identity
+
[[Image:PromiseFinal.PNG]]
Patient identity
+
 
Clinician Identity
+
==Action Items==
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.
+
* Action Item update September 1, 2011
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.
+
** Patrick to look at putting all together section doesn't logically follow the SM above, due to edits. (Patrick)
Initiator Name Information Promise State Transitions Broker State Transition
+
* Future Items - out of scope for Lab Order Release 1
Before After Before After
+
** future: Need to look at JK broked fulfillment section (Jean)
Fulfiller Query Patient identity Initial Searching No Change
+
** future: order broker section (Jean)
Broker Query Response Patient identity
+
** future: order manager (Austin)
(Request Info)n No Change No Change
+
** future: Standing order tracking fulfillment story board
Broker Auction Request identity
+
** future: other pending order (np orders, md student orders) which require supervision
Patient identity
+
** future: order authorization
Clinician Identity
+
** future: add Austin’s public health storyboard?  Namely CDC requests specimen, local lab system ‘places’ order – public health entity is the fulfiller.i
Test list Initial Costing No Change
 
Placer Bid Request identity
 
Cost Costing Bid Wait for outcome of Auction
 
  
+
==Appendix A - Comments, Questions, Concerns Summary==
Appendix A - Comments, Questions, Concerns Summary
 
  
Two-step request/fulfillment breakdown works nicely (no next step, just confirmation of the general architecture).
+
* We realize this is early in the process, but both Austin and I (Patrick) were surprised that we didn’t see more of the ‘new’ language of behavioral framework (words like collaborations, exchanges, contracts, etc).  Of course, could be this is too early and that’s the next step (or a step after).
Need to handle minimal use case which is order, then result (report) with no promise.  (review doc again with this idea in mind, some of the wording does need to change, I think).  Next step (JK to ensure promise isn’t mandatory throughout)
+
** LC: Behavioral framework terms coming in via the Roles and Interactions section as the models created based on the storyboards. Need to update the document as we elaborate
Storyboards need work.  What’s included is a good start but many need clarification.  Next step: AJK and PEL to suggest modifications to included storyboards and create new ones if needed.  Need storyboard which shows minimal path (request with specimen included, result report), a good complex path (let’s use micro since this also shows prelim vs. final reporting, include corrected with this storyboard), a repository path (order broker), and order manager (edge use case, I think).
+
* We are seeing new ‘states’ as they relate to services which break down differently than messaging (of course).  But it’s difficult to tell how the various HL7 state machines map to the service states.
Redo state machines (JK) – do we need another view or do we wait until next, more detailed iteration?  This doc is more of a DAM for a behavioral framework.  That’s in next step.
+
* Notes/questions from modeling effort
Need to ensure messaging, services, and documents are in scope of the solution.
+
** Information structures - Request/Request Component. Need to deal with nested nature of requests
Framework concept model for OO including down a notch into services (JK)
+
*** Patrick to look at entities to consider nested requests
Think introducing the idea of a broker in this particular doc is implementation-specific?  Need to support the bf of brokering.  May need to add variety of accountability paradigms (JK).  GG to review.
+
** Promise Management - is this really a separate service or is it managed by the fulfillment contract?
We realize this is early in the process, but both Austin and I were surprised that we didn’t see more of the ‘new’ language of behavioral framework (words like collaborations, exchanges, contracts, etc).  Of course, could be this is too early and that’s the next step (or a step after).
+
*** LC - so far, promise is not a separate service, but an information object that is managed by the fulfiller
We are seeing new ‘states’ as they relate to services which break down differently than messaging (of course).  But it’s difficult to tell how the various HL7 state machines map to the service states. In one of the last diagrams, we do see the suspend state (so that’s a start).  Next step: Austin and Patrick to review current state machine, lab result and bring back any that are not addressed in current doc.
+
** Separate service contracts behind the fulfillment manager
Need to buffer up use case re: order manager.  One of the peculiarities of order management is that of recurring orders.  Both the BF and the information model needs to handle. Need a storyboard which illustrates this requirement. Next step: Austin and Patrick to create storyboard
+
** Clarify collection and request lookup flows in business process model. Should lanes be separated?
Need to review, in gory detail, all the state machines for request and for fulfillment. Review on a call with Austin, Patrick, Grahame, John K
+
** At the conceptual level, the Fulfillment Manager role is accountable for the communicateResult operation, so it should be modeled with that service, as a push that might be implemented by a variety of message exchange patterns at the logical level (polling / push notification / etc). EA does not easily let you express this in a conceptual level interaction diagram - for now, handling this with notes on the model.
 +
*Notes from EA / package structure configuration
 +
**MnM has said they prefer XMI 2.1 as model serialization format, since it is more shareable with other tools. In Enterprise Architect, I can export a package/model to 2.1 for sharing with other tools, but I cannot save to that format when creating XMI to use with Subversion version control and HL7 GForge
 +
**EA svn alias used %hl7-oo-gforge%
 +
** Current version of EA 9.0.907
 +
*Other notes
 +
** Artifact definitions are being developed and clarified by MnM. Ongoing work here means change to the definitions is happening - we will manage those shifts by synching up with their requirements at defined points in our documentation creation, rather than continually trying to keep up

Latest revision as of 04:32, 18 January 2012

Link back to project page BF Alpha Project

Laboratory Ordering and Fulfillment

The Architecture Review Board (ArB) in conjunction with the Orders & Observations Work Group selected the Laboratory Domain to challenge the new SAIF Behavioral Framework and methodology. OO and the former Lab SIG/WG were stuck for years in balloting by a negative vote which Lab itself was unable to solve (and therefore, Lab eventually withdrew the Lab Order topic). That negative had at it's basis a negative-major comment regarding the lack of a current dynamic model and balloted artifacts to sufficiently communicate the Laboratory Ordering interoperability behaviors.

Document Status

Note that this document is in development, so pre-draft. It’s being circulated amongst a few HL7 work groups to socialize the discussion topics which lead to the foundation of the SAIF behavioral model requirements. Feel free to provide feedback; with that understanding (this is pre-draft). To find unfinished parts, search for <???> and for Discussion point: The <???> denote places where the core authoring team is adding content. Discussion point: items are so tagged to initiate places for OO, et. al. to discuss

Document Purpose

The purpose of this document is to highlight and discuss requirements for the SAIF behavioral model (aka dynamic model) as well as recommended business and technical artifacts needed to support this new model. The basis or source of business information for this document is healthcare services storyboard narratives, specifically those about lab ordering and resulting, collected from the International HL7 Standard, Canada, United Kingdom, and Australia. The intended audience for this paper is the Health Level 7 International Organization (HL7).

Overview

The HL7 Architecture Review Board is proposing that HL7 use a new framework for developing standards. The framework, called Services-Aware Interoperability Framework (SAIF), is based on principles from a few industry standards (e.g. RM-ODP, SOA) customized for the specific standards environment which is the business of HL7. This framework is defined and described by four components:

  • Enterprise Conformance and Compliance Framework (ECCF)
  • Governance Framework (GF)
  • Behavioral Framework (BF)
  • Information Framework (IF)

The Behavioral Framework includes a behavioral model which documents the ‘actions’ during the exchange of information between systems. In the current HL7 methodology, this is referred to as the dynamic model.

The key concepts in the current dynamic model are trigger events (what is the receiving system to ‘do’ with the information communicated), receiver responsibilities (what other activities does the receiving system perform in response to receiving a communication), triggering events (what happened on the sender side that caused this exchange of information), and status codes (represents the ‘state’ of objects within a communication). See Appendix B for a list of dynamic model requirements as seen through a MIF (model interchange format) viewpoint.

In SAIF, the behavioral model is the definition and description of expected behaviors the sender is requesting the receiver to perform with the included information model. Prior to SAIF, this was called the dynamic model and included trigger events and receiver responsibilities. To determine and discuss the requirements for the SAIF behavioral model, this document will start with simple use case narratives (storyboards) and progress towards more complex use cases with discussion after each narrative to elaborate behavioral model, information model, and governance model impacts unique to that narrative focusing on the behavioral aspects.

This discussion document initially frames behavioral requirements via HL7 storyboard narratives from the Laboratory domain which describe increasingly complex behavioral interoperability paradigms. The Lab domain is the most complex set of behavioral/process flows owned by the Orders and Observations Work Group and was chosen as the basis for behavioral model discussions in this document.

Following each storyboard narrative is a breakdown of the represented business process, objects for exchange, and the state or status of each object if appropriate. From these data points, requirements will be abstracted and documented.

Business Scenarios

Below follows business scenarios and processes with discussion immediately after each to highlight relevant points from that particular scenario or process.

Storyboards and Discussion

Below follows storyboards and discussion immediately after each to highlight relevant points from that particular use case or set of use cases.

Roles and Interactions

The initial use cases can be broken down into interactions between a sender and an intended receiver (who is also the fulfiller). In terms of the Behavioral Framework, these are the Commissioning Party and the Responsible Party. Based on the role and accountability / obligation we can derive a set of business services that realize the required behaviors and manage the appropriate state transitions. These services can be composed into interactions and interoperability scenarios and implemented by a variety of exchange patterns (request/response, publish/subscribe, synchronous or asynchronous messages, etc).

 LC Comment:
 Working on recasting this into the language of the Behavioral Framework. Commissioning Party, Responsible Party, Obligations, Operations, Information Exchange, Exceptions.
 I will leave comments to indicate where I am in progress, then remove them as I work through it.

The first thing is to identify the roles. So far, we have:

Role Description BF Mapping
Order Requestor (Placer in v2) Places the original request, and waits for it to be completed Commissioning Party
Request Fulfiller) Accepts the request, and then carries out the activities to fulfill what was asked Responsible Party
Fulfillment Manager Monitors the Order Requestor as it receives activities which fulfill the original request and determines when the fulfillment activities ‘complete’ the request May be the commissioning or the responsible party at different stages of the business process flow
LC Comment:
 As we work through the use cases identifying operations with related information objects, this next table should be transformed into one with headings
 Commissioning System Role || Required Interface || Responsible System Role || Responsible Agent / Service Interface || Operation
 
 The operations each then wrap the information payloads, carry out specific obligations and effect the state transitions, and may eventually define exceptions. 
 If we think this is the correct path, the next suggested step is to attempt a UML computational model based on the use cases, then revisit this table. 

The state transitions in the request and promise class are linked by exchanges between the systems that play the two roles. They can be presented in a tabular form:

Initiator Exchange Name Information Request State Before Request State After Promise State Before Promise State After
Order Requestor Request Request identity
Patient identity
Provider identity
Test list
Null Active Null Request to Fulfill
Fulfiller Accept Request identity
Patient identity
Predicted Delivery
time?
Null Promised Request to Fulfill Intent to Collect
or
Intent to Fulfill
Fulfiller Refuse 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 Fail Request identity
Patient identity
Reason for Failure
Active Aborted Intent to Fulfill Aborted

These interactions can be assembled into services using either request/response, publish/subscribe, or implemented using synchronous or asynchronous messages. But whatever the architecture, these are the essential information exchanges that need to occur. Missing from this table are other obligations that the order requestor and fulfiller have. Some of these obligations are shared in all the various incarnations of the lab request/report cycle, while others vary wildly. The most obvious obligations pertain to the fulfiller:

  • Carry out the work that is promised (if possible – i.e. can’t do it if the patient doesn’t turn up)
  • Ensure that either a complete or failed exchange actually happens in the end

Other obligations might be to validate that the request is valid, or to inform other systems, or to perform some further business processing. These obligations are out of scope when building an interoperability standard, as are the obligations on the placer such as ensuring that the order is one it is allowed to submit.

Additional Requirements

However, this is not all there is to lab orders. There are several key additional requirements that need to be provided for.

Order Brokers

Order Manager

The most common end state for the request cycle is that the laboratory or fulfiller claims that request has been completed. An important question is whether the placer agrees that whatever was requested has actually been performed. There are several reasons why the placer may not agree:

Clerical Error The whole point of this request cycle is that there should be no capacity for clerical error
Configuration Error The mapping between the request code and the lab system test code may be in error
Clinical Interpretation The lab applies clinical judgment when deciding what to do; there may be disagreement between the clinician and the lab in this area.

For this reason, many clinical systems that place lab requests provide functionality to check what was performed against what was requested; this is known as an “Order Manager”. It also tracks the requests so that some clinical user can be alerted in the case that requests are not progressing or completed – for instance, if the patient does not attend any lab to have their specimen(s) collected.

PEL Comment:
Order managers also typically manage what are called “Parent” or “Recurring” orders. Order manager functionality may be part of
the placer system, filler system, or an independent system. An order manager can take a parent order, explode it into occurrence
(aka. Child orders) which are then sent to the filler system. An order manager may also take a “composite order, explode it into
individual orders and forward them onto the appropriate departmental filler system. This is the idea behind our V3 Composite order.

AJK: An example of exploding a composite order, consider a composite order containing both an Rx order for warfarin and a recurring lab order for PT/INR. The order manager would explode the composite order into the drug order, which is forwarded to the pharmacy application, and the lab order, which may be exploded into a series of occurrence orders that are sent to the lab application at the appropriate time.

In order for the Order Manager to function, it must be able to track the laboratory reports and compare the list of reports received, along with their status and contents, against its own expected list. To enable the Order Manager to track the reports, all the reports that the lab sends to the placing system must identify the request(s) that the report is considered to be fulfilling. As discussed above, this may occur even after the request/promise cycle is complete.

When the order manager detects an issue, it must notify a human. There are no request or promise state transitions related to the order manager. However there is an exchange related to the order manager: the order manager may inform the laboratory that it has detected an issue as well as informing its own users through some process that is out of scope for this analysis. In order to treat this consistently, we can define an order manager object, along with a laboratory equivalent.

TrackerObj.PNG

Again, these objects do not have an explicit identity of their own that we interested in, and they do not need to directly exist in that form – all this is saying that from an external perspective, the systems behave as if these objects exist.

TrackerSM.PNG

These are very simple state transition diagrams. There are many other potential states related to the interaction of the logical trackers with humans (review, mark-off, etc), but these are not relevant to the request/promise cycle.

Putting it all together

Taking all these extra factors gives us final state transitions for request and promise that look like this:

RequestFinal.PNG

PromiseFinal.PNG

Action Items

  • Action Item update September 1, 2011
    • Patrick to look at putting all together section doesn't logically follow the SM above, due to edits. (Patrick)
  • Future Items - out of scope for Lab Order Release 1
    • future: Need to look at JK broked fulfillment section (Jean)
    • future: order broker section (Jean)
    • future: order manager (Austin)
    • future: Standing order tracking fulfillment story board
    • future: other pending order (np orders, md student orders) which require supervision
    • future: order authorization
    • future: add Austin’s public health storyboard? Namely CDC requests specimen, local lab system ‘places’ order – public health entity is the fulfiller.i

Appendix A - Comments, Questions, Concerns Summary

  • We realize this is early in the process, but both Austin and I (Patrick) were surprised that we didn’t see more of the ‘new’ language of behavioral framework (words like collaborations, exchanges, contracts, etc). Of course, could be this is too early and that’s the next step (or a step after).
    • LC: Behavioral framework terms coming in via the Roles and Interactions section as the models created based on the storyboards. Need to update the document as we elaborate
  • We are seeing new ‘states’ as they relate to services which break down differently than messaging (of course). But it’s difficult to tell how the various HL7 state machines map to the service states.
  • Notes/questions from modeling effort
    • Information structures - Request/Request Component. Need to deal with nested nature of requests
      • Patrick to look at entities to consider nested requests
    • Promise Management - is this really a separate service or is it managed by the fulfillment contract?
      • LC - so far, promise is not a separate service, but an information object that is managed by the fulfiller
    • Separate service contracts behind the fulfillment manager
    • Clarify collection and request lookup flows in business process model. Should lanes be separated?
    • At the conceptual level, the Fulfillment Manager role is accountable for the communicateResult operation, so it should be modeled with that service, as a push that might be implemented by a variety of message exchange patterns at the logical level (polling / push notification / etc). EA does not easily let you express this in a conceptual level interaction diagram - for now, handling this with notes on the model.
  • Notes from EA / package structure configuration
    • MnM has said they prefer XMI 2.1 as model serialization format, since it is more shareable with other tools. In Enterprise Architect, I can export a package/model to 2.1 for sharing with other tools, but I cannot save to that format when creating XMI to use with Subversion version control and HL7 GForge
    • EA svn alias used %hl7-oo-gforge%
    • Current version of EA 9.0.907
  • Other notes
    • Artifact definitions are being developed and clarified by MnM. Ongoing work here means change to the definitions is happening - we will manage those shifts by synching up with their requirements at defined points in our documentation creation, rather than continually trying to keep up