Link back to project page BF Alpha Project

Laboratory Request

Executive Summary

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

Open Issues

Comments from Cindy V.:
- Conceptual Roles: I suggest changing “healthcare information” in the description for the 2 systems to “laboratory information”.
  - PEL> Agree with change to Lab System actor. Will make the change
  - PEL> Do not agree with change to POS system. That actor is more general and available to everyone, not just lab. the intent of SAIF is to create re-usable bits. Overspecifying causes to lose this.
- Conceptual State Model: I think it would be helpful to have a state model in the storyboards or before the comprehensive state model. This would fill in the gaps and help mess the see the derivation of “the following request object states and transitions from the above storyboards”.
  - Agree. Will add storyboard specific state machines for understandability as well as 'master' state machine
- Conceptual State Model: The paragraph after the 1st state model starts “As you can see, the request object”. Frankly, I cannot see how the state model tracks from the storyboards. In addition, you use different terms in the state model such as fulfiller, fulfillment resolution, etc. that aren’t defined or, otherwise, explained.
  - Agree. Wording is left over from requirements document. Will reword accordingly.
- In Contract Roles and Agents, you are using different terms for the Commissioning System Role and the Responsible System Role without linking them to the terms in the event flow (Provider Order Management System: Ordering System, Laboratory Point of Service System: Specimen Collector System, & Laboratory: Laboratory Information System). It would help in reading the more system-centric diagrams if this connection was made.
  - Agree. Will align.

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 service provider to accept, modify, or reject an order, with appropriate intent indication to the orderer. Modification may include breaking a parent order into child orders or work items Modification include substituting a particular test Available/orderable Laboratory services may be described by an act in definition mood.

Business Function

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

Basic business process steps:

Diagnostic (or Public Health) Specimen-based Laboratory work requested for a subject (patient, animal, environmental location, etc)
Specimen collected from subject
Specimen accessioned by lab (i.e., enters lab testing process)
Specimen processed into testable samples
Samples tested by lab
Results from lab testing obtained, interpreted, and approved/authorized
Results returned to requester
Requester determines next steps and course of action

Conceptual 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 not assumed in the above steps and may not be present depending upon the conditions under which each step is performed.

Conceptual Role

Storyboards and Activity Diagrams

Information Model Conceptual Artifacts

Conceptual Information Model

 Comment:
   Provide links to the Analysis Information Model for the domain

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

Conceptual Data Types Model

Conceptual State Model

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

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.

Concept Domains

ActStatus
LaboratoryOrderableTestCode
LaboratoryQualitativeResultCode
DocumentTypeCode

Solution Specification

Scenario #1 - Simple Lab Order

Overview

Business Scenario

The event flow for a simple lab order is shown below

File:Create Laboratory Order Activity Diagram.png

Contract Roles and Agents

The commissioning and responsible parties involved in this process include:

Commissioning System Role	Responsible System Role	Operation
Order Requestor (Placer in v2)	Order Request Manager	createRequest
Order Request Manager	Fulfillment Manager	createRequest
add	add	add

Computational Viewpoint

The following sequence diagram depicts the interactions that support the above event flow

Service Dependencies

 Comment:
   Describe any dependencies of the process being specified

The parties supporting this process are the Order Request Manager and Fulfillment Manager, depicted below

Implemented Patterns

 Comment:
   Indicate the any patterns that apply to this process specification

Contractual Semantics and Issues

Conformance Statements

Comment:
   define the conformance criteria for this specification

Computational Services

Order Request Manager

Order Request Manager Conceptual Specification

Fulfillment Manager

Fulfillment Manager Conceptual Specification

OO Behavioral Model Conceptual Specification

Contents