Laboratory Order Conceptual Specification

Link back to project page Laboratory Order

Laboratory Request

Executive Summary

• This document contains the necessary definitions, descriptions, graphics, and artifacts relevant to the development of logical and implementable artifacts for an electronic request for healthcare services between an ordering provider and a performing laboratory. In this document, laboratory testing refers to the collection, processing, and analysis of specimens.

Business Model Conceptual Artifacts

Business Context

• The laboratory domain comprises the models, messages, and other artifacts that are needed to support messaging related to laboratory tests, or observations.

• The HL7 Laboratory domain includes the provision and use of analytic services in areas such as chemistry, hematology, serology, histology, cytology, anatomic pathology, microbiology, and virology. It does not include blood bank or blood transfusion services. (Note that not all lab specializations will be supported in this first HL7 V3 R1 of the Laboratory Request Topic.)

• Analytic services typically result in observations returned to the order placer and/or added to the patient medical history. Observations may be simple numeric quantitative measurements, such as a blood serum glucose level, qualitative measurements such as micro-organism susceptibility to a particular antibiotic, or complex diagnostic pathology reports.

• Services may be delivered/executed at a external lab, an on-site lab, or at the point of care. This topic covers service requests from all locations, including bedside and in-hospital, clinic and outpatient, and lab-to-lab interactions. It includes orders accompanied by specimens to be analyzed, as well as orders for which the performing laboratory is responsible for obtaining the specimens. Observations (results) may be generated for both ordered and unordered (e.g., POC) tests.

• Workflow includes ability of performing laboratory to accept, modify, or reject an order, with an appropriate indication sent back to the orderer. Modification may include breaking a parent order into child orders or work items.

Business Function

For this specification, the business function at its most basic is about ordering (requesting a healthcare service) and the fulfillment of that request by filling entities.

Basic business process use case bubble diagram

The following bubble diagram describes the ordering business process.

Conceptual Roles

Processes

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. Conversely in acute care settings, the business process for laboratory specimen testing is quite rich as the order placer and laboratory perform more electronic exchanges, usually centered around specimen collection.

Laboratory Business Process

For Laboratory Diagnostics (specimen testing), the following illustrates high-level business functions:

1. Diagnostic (or Public Health) Specimen-based Laboratory work requested for a subject (e.g., patient, animal, environmental)
2. Specimen collected from subject
3. Specimen accessioned by the Laboratory (i.e., enters lab testing process)
4. Laboratory sometimes communicates an intent to perform the work requested
5. Specimen processed into testable samples, tested, and analyzed
6. Results from lab testing interpreted, documented, formatted, approved/authorized
7. Laboratory sometimes formats the results as a report
8. Results returned to requester
9. Requester determines if all requests have been fulfilled, next steps and course of action

From which a set of concepts representing the state or status of a laboratory order can be derived.

Laboratory Business Process Assumptions

While the above list shows the performed steps in a basic lab ordering/fulfillment process, each of these steps may be performed by different actors/roles in any one specific process; for example, a Clinician, Laboratory Technician (e.g., phlebotomist), Investigation Team Member, the Subject (patient), or a person responsible for a Subject may collect the specimen. In addition, the steps may be performed at different locations; specimens may be collected at the point of care, at the subject's location (e.g., at a patient's home, "in the field", etc), in the testing lab, or at a specimen collection organization. The steps may also be performed in different order or not performed at all under given, specific conditions - a specimen may not require any processing prior to being tested or a specimen is assigned an accession number prior to being collected if it is being collected in the lab.

Finally, the involvement of an electronic system to capture the information and facilitate the business process is assumed in the above steps and must be present depending upon the conditions under which each step is performed. All step-specific conditions and event-specific conditions are documented in the process-specific section of this specification. Note that this specification is for interoperability between electronic systems; manual processes are documented as they relate to information exchange and are ignored otherwise.

Laboratory Business Process Workflow

The business process documentation above describes the generic steps in the performance of a request for laboratory services. This view of the laboratory business has another dimension which is a further specialization of the concept of the request. That specialization, sometimes referred to as workflow event, further clarifies whether the request is for a new service (not having been communicated bewteen systems previously); or if this request is a 'request to change' an order previously submitted and communicated; or a request to cancel.

Laboratory Business Process Workflow Narratives

The following are the in-scope business workflow-specific processes:

• Create Laboratory Order
• Change Laboratory Order
• Cancel Laboratory Order
• Query Laboratory Orders

Process - Create Laboratory Order

Process Storyboards - Create Laboratory Order

Storyboard (Universal) - Create Lab Order (Lab Collect)

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 entered into the information
in the lab system. 

The lab performs the analysis on the specimen(s), enters the results into 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 (Universal) - Create Lab Order (Provider Collect)

Adam Everyman, a 53-year-old male, has an appointment with Dr. Carl Cardiology at Good Health 
Hospital Outpatient Clinic.  Adam reports a history of Anemia and recent, excessive tiredness.  
Dr. Cardiology enters a request to check the iron levels in Adam’s blood into his care system.  
Dr. Cardiology’s care system then sends the test requests to  the lab system at the Good Health 
Hospital’s Laboratory service.  Dr. Cardiology’s staff collects the necessary specimen(s), 
labels them, packages them and ships them to the laboratory. 

The lab receives the specimen(s) and accessions each.  Specimen is evaluated for use by the 
Laboratory Technician.  Next, an analysis is performed on the specimen(s), the results are added 
to the lab system and QA'ed as appropriate.  Upon completion of QA, the results are structured as 
a report document using CDA.  The report is then sent to Dr. Cardiology’s care 
system reported as final.  Dr. Cardiology reviews the results, formulates a treatment, if needed, 
and notifies Adam Everyman of the results and any follow-up treatment.

Storyboard (Universal) - Create Lab Order (3rd Party Collect)

There are scenarios where the specimen collector is different from the provider or lab, who travels to each patient in order to perform specimen collection procedure(s).

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 calls a 3rd Party collection service.  The service looks up and 
finds the order for her testing in the regional repository.  The 3rd party collector 
then travels to the patient location.  The appropriate blood samples are 
extracted, their containers labeled, and the sample information added to the information
in the repository. 

The lab receives the specimen(s) and accessions each.  Specimen is evaluated for use by the 
Laboratory Technician.  Next, an analysis is performed on the specimen(s), the results are 
entered into the lab system and QA'ed as appropriate.  The lab performs the analysis on the
specimen(s), enters the results into 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 follow-up treatment.

Process Description - Create Laboratory Order

Patient Presents. Provider observes, measures, evaluates, and analyzes patient, then orders specimen-based diagnostic testing. Specimen is collected. Specimen is accessioned, tested, analysed. Results of testing are documented, formatted, approved. Results sent to original requestor.

Process Actors - Create Laboratory Order

Note: What does primary/secondary mean?  Should this be removed or replaced with conformance (required or optional)?  Escalate issue to ArB

Name	Human/NHLS/Substance/System
Subject/Patient	Human/Non-Human Living Subject/Substance
Provider	Human
Ordering System	System
Specimen	Human/Non-Human Living Subject/Substance
Laboratory Information System	System
Laboratory Professionals	Human

Process Scope - Create Laboratory Order

A healthcare provider needs specimen-based diagnostic testing on a patient. This is the initial request; no request has previously been communicated for the same service at the same date/time.

Process Event Flow - Create Laboratory Order

Below is the event flow for Create Laboratory Order which defines the necessary activities, decisions, and information exchange points. The Laboratory Order Repository needed for the 3rd storyboard above is handled via an alternate flow and is not represented in the diagram below.

Process Alternate Flows - Create Laboratory Order

• Alternate Flow 1
  • Description: Order Repository
  • In order to deploy ordering to a region, vs. a single facility or set of facilities, an architecture which includes a repository is common. This alternate flow includes the deltas from the main flow to accomodate changes necessary to the workflows when a regional order repository is used.
  • Details: TBD next version
• Alternate Flow 2
  • Description: Specimen Problems not resulted
  • If the specimen has been determined to be unsuitable for testing, the performing laboratory contacts the ordering provider. It is a current assumption of this use case that the communication of unsuitable specimen(s) is performed using a result.
  • Details: TBD next version

Process Pre-Conditions - Create Laboratory Order

• User has create functionality and permissions

Process Post-Conditions - Create Laboratory Order

Laboratory order requestor (placer) is satisfied that the laboratory performed the tests as requested within the current conditions and has documented and communicated those results to the order requestor.

Process Special Requirements - Create Laboratory Order

None identified.

Process Extension Points - Create Laboratory Order

None identified.

Process Business Rules - Create Laboratory Order

• Orders must represent an action that can be performed by the order fulfiller.

Change Laboratory Order - Process

Universal Storyboard - Change Lab Order (Provider Collect)

Adam Everyman, a 53-year-old male, has an appointment with Dr. Carl Cardiology at Good Health 
Hospital Outpatient Clinic.  Adam reports a history of Anemia and recent, excessive tiredness.  
Dr. Cardiology enters a request to check the iron levels in Adam’s blood into his care system.  
Dr. Cardiology’s care system then sends the test requests to the lab system at the Good Health 
Hospital’s Laboratory service.  Dr. Cardiology’s staff collects the necessary specimen(s), 
labels them, packages them and ships them to the laboratory.

The next day during a review of Adam's chart, Dr. Cardiology determines that he needs to order 
an additional test.  Dr. Cardiology or his staff updates their local system to change 
(revise/modify) the order which is then communicated to the lab system.  Since the specimen 
was already sent to the lab, the staff then contacts the lab to ensure they are aware of the 
requested change.

The lab receives the specimen(s) and accessions each.  Specimen is evaluated for use by the 
Laboratory Professionals and whether there is an adequate volume of suitable specimen to
accomodate the additional tests.  There is sufficient specimen; therefore, the analysis is
performed on the specimen(s), the results are added to the lab system and QA'ed as 
appropriate.  Upon completion of QA, the results are structured as a report document using
CDA.  The report is then sent to Dr. Cardiology’s care system reported as final.  Dr. 
Cardiology reviews the results, formulates a treatment, if needed, and notifies Adam Everyman 
of the results and any follow-up treatment.

Change Laboratory Order Event Flows

Next is the event flow for Change Laboratory Order. Note that any change is a 'request to change'. Depending on the situation, the performing laboratory may reject the change.

Cancel Laboratory Order Event Flows

Next is the event flow for Cancel Laboratory Order. Note that any cancel is a 'request to cancel'. Depending on circumstances, the test may be able to be cancelled up to the point that the test is completed or not cancellable if the specimen was collected.

Information Model Conceptual Artifacts

Conceptual Information Model

The following classes were derived from the storyboards and use cases.

Conceptual Data Types Model

The following conceptual data types are referenced from the information model

Conceptual State Model

There are a couple of different types of state models. The first is representing the status of the whole business process. The states are represented as statuses which correlate to Key activities on the event flow. The second are a set of state models, one for each Key information object, defining the appropriate statuses for each object.

For the business process state machine:

We can derive the following request object states and transitions from the above storyboards:

In the Lab Order conceptual State Machine, notice that 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.

Concept Domains

• ActStatus
• LaboratoryOrderableTestCode
• LaboratoryQualitativeResultCode
• DocumentTypeCode

Solution Specification

Computational Viewpoint

Overview

Business Scenario

The event flow for a simple lab order formed the input for the interactions and contract roles described here.

Contract Roles and Agents

The parties supporting this process are the Order Manager and Fulfillment Manager, depicted below. Specimen collection is a constrained profile of Order Management. As described in the event flows above, the Specimen Collection role may be performed by the Provider, the Lab or a third party specimen collector.

System Actors from the storyboards above may implement one or more contract roles

Scenario 1 - Create Lab Order

The following sequence diagram depicts the interactions that support the Create Lab Order event flow

Scenario 2 - Change Lab Order

The following sequence diagram depicts the interactions that support the Change Lab Order event flow. The specimen collection step is optional, as it may have already occurred when the change request begins.

Scenario 3 - Cancel Lab Order

The following sequence diagram depicts the interactions that support the Cancel Lab Order event flow. If the specimen is already collected, the order cannot be cancelled.

Contractual Semantics and Issues

Conceptual conformance statements defined by this specification will be further refined at the logical and implementable levels. Conceptual conformance statements may require evaluation by humans rather than automated tests to confirm conformance.

• Contract roles define the operations that realize a specific set of accountabilities. Profiles on the contract roles defined subsets of operations that are intended to work together. Implementations claiming conformance to a specific profile must support all operations of that profile

• Information objects used in operations must conform to the defined static representations. The information classes will be further refined at the logical level based on the specification paradigm. For instance, for version 3 models, information structures will be represented by RMIMs.

• Services may be composed to support an unlimited number of interoperability scenarios. This specification describes representative business interaction scenarios, but does not attempt to limit conceivable interactions to those described. In particular, the scope of this specification focused on a simple lab order. More complex scenarios will result in more complex interaction patterns.

Conformance Assertions

• Each subject must be identified by an identifier that is unique within the namespace/assigning authority assigning the identifier.
• The minimal allowable steps of lab process are the request and the result. All other steps are optional
• Business states are not directly mappable to HL7 Act States - they are different state machines.

<note - this section is expected to elaborated further in future revisions of these artifacts>

Computational Services

Order Manager

• Order Manager Conceptual Specification

Fulfillment Manager

• Fulfillment Manager Conceptual Specification