Lab AU SB Report

Back to Conceptual BF Document

Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient
Clinic and is seen by Dr. Debbie Dermatologist. Eve reports a history of skin problems
and Dr Debbie does an evaluation of a few ‘spots’ on Eve’s face and nose.  Dr. Debbie
takes a skin scraping for analysis of one of the spots.

Dr. Debbie enters the requested test into her care system, which sends the tests to
the Good Health Hospital’s Laboratory service.  When the laboratory service accepts
the tests and promises to perform them, the promise is communicated to Dr. Debbie’s
care system.
 
The lab performs the analysis on the received specimen and formats the results into a
clinical report. The results meet the established criteria for releasing the report,
but not for automatically authorizing the report, so the Lab system sends an interim
or provisional report to Dr. Debbie’s Care System.

Later, the report is reviewed by a qualified Pathologist who approves it, and the lab
system sends a final report to Dr Debbie’s Care System.

Business Process

This is a more complex business process as it adds two more objects and potentially many more exchanges of information between systems. In this use case, a Promise is communicated from the fulfilling system to the requesting system with an ‘intent to perform’ an action or set of actions in response to the request. Note that there is a different object for the report in addition to a result object. A report is a document, captured at a point-in-time, authenticated, which contains results and a human-readable representation of the results.

Storyboard Objects

From this storyboard and the implied business process, we can derive six objects that the interactions that occur are concerned about:

The request, fulfillment, and result objects are the same as the simple use case. However, the more complex use case introduces three new objects: Promise, Reporting and ReportDocument. Additionally, introduction of these three objects does increase the number of states (or statuses) for the fulfillment object itself.

The Promise object is created on the Lab Information System when that system communicates that the lab intends to perform testing in response to the request. It will have an identity of its own, and it will contain some link to the patient Eve, the request identity, the requested tests, and the promised test(s). Note that the list of promised test(s) is not always the same as the requested test(s). There are circumstances where the lab cannot perform the test as ordered (for example, lab intends on using a different method vs. the requested method).

The Reporting objects are tied directly to the Results objects and asserts whether a particular result is preliminary, final, or corrected. The Reporting object is associated with the reporting process step for each result.

In addition, each of these objects has a status. We can derive the following states and transitions from the storyboard for the Promise object:

For the Promise, initially the Lab receives a request for fulfill diagnostic testing for a patient on a specimen. Whether the specimen has already been collected, or is expected to be collected, is a relevant point to what the lab is promising to perform. There are, therefore, separate states to represent the difference between communicating an ‘intent to collect’ vs. an ‘intent to fulfill’ the request. Once resulting is complete, the promise is expected to be completed similarly.

Once a request arrives, the lab system decides whether it’s going to promise to perform the request, depending on configuration. This might a simple decision – automatically yes; or it might require confirmation from a human potentially somewhere else to grant financial approval. If the lab does communicate the intent to perform the requested tests, a promise is sent and the lab system moves into a ‘working’ state. Note that the working state of the lab system isn’t represented in the object status diagrams as this state is internal to the lab system and isn’t a concern of interoperable functionality. Interoperable functionality is about interactions between the externally observable states of the systems which cause information exchange. Some state models, particularly internal models, would not have the state ‘working’ instead using the state ‘intent to fulfill’ meaning an intent to fulfill was communicated but not yet resolved or completed.

We can derive the following states and transitions for the Reporting object:

The Reporting object communicates the business status of the result. Specifically, whether the report has been finalized (implying all QA is complete, the result is ‘signed’ by the Medical Director), prior to finalized (so, preliminary), or corrected. Although all three states are not covered in this scenario, all are presented as a complete list for brevity. A later scenario details the usage of the corrected Reporting status. Finally for this storyboard, we have the report documents themselves.

We can derive the following states and transitions for the ReportDocument object:

In an interim result report, the data is available but not all the QA processes are complete on it (usually human review); so the Result is made available on a provisional or preliminary basis. The result ReportDocument may be recorded and communicated; but the document is not yet authenticated. For some results, the Result and ReportDocument are not made available until all QA is perform based on clinical risk assessment, while for other occasions the timely availability of unQA’ed results is actually the lower clinical risk (usually there’s a time urgency involved). Once the QA is complete for any result reported as preliminary and all additional processing complete (for example, micro-biology testing), the result is reported as final, the document authenticated, recorded, and usually communicated.

Note that the lab processes of resulting and reporting continue after the request/promise cycle has been finalized. For instance the lab system may advise the care system that the tests it requested are now complete (final), and then subsequently an error is discovered, leading to the issuance of a corrected (Reporting) result and an amended report. It must not be necessary to re-activate the Request, the Fulfillment, or the Promise in order to send a correct Result and an amended ReportDocument. There’s no business process reason for the Request, Fulfillment and Promise status to change – the lab simply sends the amended report. In addition, there may be other business workflows that lead to the lab sending reports to the care system which had no care system request associated with them at all. So it’s both easier and more faithful to real life to treat the Reporting object and ReportDocument object as separate entities.

Back to Conceptual BF Document#Storyboards and Discussion