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 lab system at 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 looks up and 
finds the order for her testing in the lab system.  The appropriate blood samples are 
extracted, their containers labeled, and the sample information added to the information
in the lab system. 

The lab performs the analysis on the specimen(s), adds the results to the lab system, and
sends the results to Dr. Primary’s care system reported as final.  Dr. Primary reviews the
results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and
treatment.

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.

The following figure shows the flow of the simple storyboard using Business Process Modeling Notation (BPMN). This process contains 3 entities as participants: Eve Everyone, Good Health Hospital, and Laboratory Services. There are 2 roles or actors at Good Health Hospital: Dr. Patricia Primary and the Care System; and 3 roles at the Laboratory Service: the Lab system, Collection, and Analysis. Dashed lines that go between the "pools" represent information flowing from one entity (or organization) to another. Of interest to electronic data exchange are the "sends request to lab system" from Good Health Hospital to Laboratory Services and "sends results to care system" from Laboratory Service to Good Health Hospital.

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.

Back to Conceptual BF Document#Storyboards and Discussion