Lab UV SB Simple
Back to Conceptual BF Document
Universal Storyboard - Simple
To start, the simplest use case:
Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent, excessive tiredness. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system. Dr. Primary’s care system then sends the test requests to the Good Health Hospital’s Laboratory service. Eve receives a paper order requisition that serves as a reminder, provides instructions for where to find the collection center, and also details preparation instructions for the patient to follow (no food or drink from midnight until collection time on the day of collection). Later that week Eve presents herself at the Lab Collection Center. The lab finds the order for her testing and the appropriate blood samples are extracted and their containers labeled. The lab performs the analysis on the specimen(s) and sends the results to Dr. Primary’s care system reported as final.
Storyboard Assumptions
The first thing to note about this storyboard is a generic issue with many storyboards; it makes certain assumptions about each system’s connectivity (sending, receiving) to define and describe the information exchange events and their sequencing. For instance, Dr Patricia’s care system ‘sends’ the request to the lab system. It maybe that this is not necessary – that the care system will hang on to the request until the lab system goes looking for it (polling). That’s a connectivity (network architecture) aspect. But trying to write storyboards that don’t imply particular IT solutions is very difficult and tends to lead to opaque storyboards where the abstract from an IT solution gets in the way of the goal; which is to describe the process in a non-IT way. Clinicians think of results as something that are “sent”, but this doesn’t imply that the underlying IT implementation needs to actually push the results out. Doing so has pros and cons. So don’t take too much notice of IT implications but on the business processes themselves and the exchanges of information (in all forms). These storyboards are only a first step towards understanding and documenting the process.
Business Process
At its most basic, the business process documented in this use case is one of a requested service and documentation when that service is performed. Many ambulatory use cases follow this basic pattern and the only communications are the two, the first from placer to filler with the request and the second from the filler to the placer with the fulfillment of that request.
Storyboard Objects
From this storyboard and the implied business process, we can derive three objects that the interactions that will occur are concerned about:
There will be a Request object that exists on the Dr Patricia’s care system. It will have an identity of its own, and it will contain some link to the patient Eve, and the list of requested tests. The UML shows these as attributes, but with no details; they are just data place holders that assert that something meeting these functional requirements will exist.
The lab (fulfillment) system will contain one or more result objects, which exist because of the performance of the requested tests and one fulfillment object. Each result has its own identity and knowledge of the request identity, if it exists. Similarly, the fulfillment object also has an identity of its own. Note the differentiation between the fulfillment object and the result object. In almost all implementations of the storyboard, there is a single message or service interaction between systems that combines the two parts:
- delivery of the actual results that form the fulfillment of the request (result object), and
- an assertion that the request is actually filled or fulfillment status (fulfillment object).
Here, we draw these two concepts apart so that the accountability and responsibilities are made explicit for the purposes of analysis. Later, when the actual interaction instances are defined, these different aspects of the interaction may be combined into a single exchange or multiple exchanges based on the requirements. This is a consistent design pattern that we'll be trying to achieve in this conceptual discussion document; separating out the accountability and responsibilities even if they are recombined later. In addition, we're trying to separate out the cycle of request/fulfillment from the many various result and report patterns that arise during the fulfillment.
In addition, each of these objects has a status. We can derive the following request object states and transitions from the storyboard:
As you can see, the request object has a status for when the fulfiller asserts the request is fulfilled, but the request has not yet evaluated that assertion (called fulfillment resolution). There are also the two other, expected, request statuses: active and complete. In the simplest request use cases, the request only takes one of these states. We can derive the following fulfillment object states and transitions from the storyboard:
Again the status, this time for fulfillment, is restricted in this simplest use case to null and resulted.
Lastly for this simple use case, we can derive the following result object states and transitions from the storyboard:
In this use case, only the completed state is important for interoperability.
