Conceptual BF Document
Link back to project page BF Alpha Project
- 1 Laboratory Ordering and Fulfillment
- 1.1 Document Status
- 1.2 Document Purpose
- 1.3 Overview
- 1.4 Business Scenarios
- 1.5 Storyboards and Discussion
- 1.6 Roles and Interactions
- 1.7 Additional Requirements
- 1.8 Putting it all together
- 1.9 Action Items
- 1.10 Appendix A - Comments, Questions, Concerns Summary
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.
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
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).
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.
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.
- Universal Storyboard – Simple
- Universal Storyboard – Revise, Hold, Abort
- Australian Storyboard – Promise, Result Report
- Universal Storyboard – Microbiology Result Report, Corrected Result
- Australian Storyboard – Withdraw Report
- Universal Storyboard – ReportDocument Events
- Public Health Storyboard – Field Specimen Collection
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:
|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
|Null||Active||Null||Request to Fulfill|
|Null||Promised||Request to Fulfill||Intent to Collect |
Intent to Fulfill
Reason for Refusal
|Null||Refused||Request to Fulfill||Rejected|
|Active||Complete||Request to Fulfill||Complete|
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.
However, this is not all there is to lab orders. There are several key additional requirements that need to be provided for.
- Canadian Storyboard – Regional Repository
- Australian Storyboard – Test Challenge
- Australian Storyboard – Follow-up Testing/Revise Order
- John K. - Brokered Fulfillment
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.
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.
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:
- 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.
- 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?
- Patrick to look at putting all together section doesn't logically follow the SM above, due to edits. PEL revising the SM puttingg it all together section
- Need to look at JK broked fulfillment section (Jean)
- order broker section (Jean)
- order manager (Austin)
- Need to review initial roles and interactions and services (Lorraine)
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).
- 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
- Promise Management - is this really a separate service or is it managed by the fulfillment contract?
- Separate service contracts behind the fulfillment manager
- start communication diagrams matching business process flow - as it develops
- Clarify collection and request lookup flows in business process model. Should lanes be separated?