|
|
| Line 30: |
Line 30: |
| | [[image:Create Laboratory Order Activity Diagram.png]] | | [[image:Create Laboratory Order Activity Diagram.png]] |
| | | | |
| − | ==Storyboard Objects==
| |
| − | From this storyboard and the implied business process, we can derive three objects that the interactions that will occur are concerned about:
| |
| − | [[Image:Simple_result_objects.PNG]]
| |
| | | | |
| − | 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.
| + | Back to [[OO Behavioral Model Conceptual Specification|Lab Order Conceptual Specification]] (Draft) |
| − | | |
| − | 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:
| |
| − | | |
| − | [[Image:ClinicalRequestLiteSTM.PNG]]
| |
| − | | |
| − | 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:
| |
| − |
| |
| − | [[Image:FulfillmentLiteSTM.PNG]]
| |
| − | | |
| − | 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:
| |
| − |
| |
| − | [[Image:ResulttLiteSTM.PNG]]
| |
| − | | |
| − | In this use case, only the completed state is important for interoperability.
| |
| − | | |
| − | Back to [[OO Behavioral Model Conceptual Specification]] (Draft) | |
Back to OO Behavioral Model Conceptual Specification (Draft)
Universal Storyboard - Create Lab Order
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.
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 storyboard using an Activity Diagram.
File:Create Laboratory Order Activity Diagram.png
Back to Lab Order Conceptual Specification (Draft)
