Lab AU SB Follow
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: 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. 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.
