Lab Workflow for Pathology
A proposed amendment strategy for the IHE APW and LAW Profiles1
Introduction ................................................................................ 1
In-Lab Workflow Management .................................................. 2
Work Order Step Results Management ..................................... 2
Integrated HL7 and DICOM Workflow........................................ 3
Code Sets for Lab Workflows ..................................................... 4
Orders and Results Workflow..................................................... 5
Other Associated Workflows ...................................................... 5
Endorsements............................................................................. 6
Introduction
The IHE Anatomic Pathology Workflow (APW) Profile2 from IHE-AP specifies the use of DICOM Modality
Worklist (MWL) and Modality Performed Procedure Step (MPPS) for managing the imaging activities within the
pathology department. In contrast, the IHE Laboratory Analytic Workflow (LAW) Profile3 and Laboratory
Device Automation (LDA) Profile4 from IHE-Lab specify the use of HL7v2 OML, QBP and OUL messages for lab
equipment activity management.
The IHE-AP approach for workflow control is not unreasonable if imaging is considered alone, as the images
themselves need to be managed under the DICOM protocol. However, when viewed in conjunction with lab
device control it places an undue burden on the LIS, which would need to implement two distinct workflow
infrastructures for the full complement of equipment.
This position paper recommends consolidating all lab workflow management under HL7v2 messaging (the LAW
Profile approach). It discusses how DICOM Storage Services can be used in a complementary fashion to
manage persistent storage of evidentiary information objects in PACS archives, leveraging that capability
already deployed in most institutions with radiology departments. It further shows how this combination of
1
This document is available on the DICOM FTP server WG-26 folder (ftp://d9-workgrps:goimagego@
medical.nema.org/medical/private/dicom/WORKGRPS/WG26/LabWorkflow/). Please check there for more recent
revisions.
2
IHE Anatomic Pathology Technical Framework Vol.1 Section 2, and Vol.2
(http://www.ihe.net/Technical_Framework/index.cfm#pathology)
3
Supplement for trial implementation
(http://www.ihe.net/Technical_Framework/upload/IHE_Suppl_Lab_LAW_Rev1.1_TI_2012-03-09.pdf)
4
IHE Lab Technical Framework Vol.1 Section 5, and Vol. 2
(http://www.ihe.net/Technical_Framework/index.cfm#laboratory)
page 1
HL7 and DICOM could be profiled to support the anatomic pathology lab, including flow cytometry, gross
imaging, whole slide imaging, and microscope field of view imaging.
In-Lab Workflow Management
The HL7 lab workflow management is based on the Lab Information System and any Lab Automation Systems
(collectively the “Automation Manager” or “Analyzer Manager” described in the IHE Lab Profiles) managing
Work Order Steps (WOS), and receiving status from the lab devices. A WOS is equivalent to a Procedure Step in
the DICOM-based workflow. The IHE Lab Profiles further classify WOS’s as Specimen Work Order Steps (SWOS)
that do not produce results, and Analytical Work Order Steps (AWOS) that do. This paper will primarily address
AWOS.
One of the challenges with HL7 is that it is difficult to implement an interoperable “pull model” workflow, i.e.,
one that is driven by the device querying the LIS upon arrival of the specimen at the device. HL7 queries are
“implementation specific”; they typically need to be redesigned for each installation. However, the LAW Profile
establishes a standard implementation of the HL7 query capability for device pull-model workflow, and it
requires the LIS to support these queries.5
The LAW workflow query is specimen-oriented; the device queries based on a specimen identifier, or on a
position of the specimen in a carrier. The LIS acknowledges the query, and then sends the AWOS details in an
OML message, and the device acknowledges the AWOS with an ORL response.
As the AWOS is performed, the device reports status of the step using an OUL message.
The overall capability of this HL7 AWOS management is thus generally equivalent to that of DICOM Modality
Worklist / Modality Performed Procedure Step (MWL/MPPS). For managing imaging related steps, it would be
essential to ensure a mapping between HL7 message fields and equivalent DICOM fields. This will be very
similar to the mapping provided in the IHE Radiology Technical Framework between radiology order ORM
messages and MWL, but with extensions to include the specimen information.
Note that the LAW Profile describes a number of process flow variations, including re-runs, reflex orders,
exception cases, etc., which are not described here.
Work Order Step Results Management
The LAW profile does not specify how results of analytic workflow steps are managed. The results may be
returned directly in the OUL status message or, frequently for large analysis outputs, by reference pointer to a
result file on a shared file store accessible by FTP or NFS (a.k.a. network drive). Although IHE-Lab specifies how
to reference result files6, the actual long-term management of such result files is outside the scope of the LAW
profile.
5
The HL7v2 QBP (Query by Parameter) message is a generic content-free query framework. The LAW Profile defines the
query fields and associated vocabulary for use of QBP as a Work Order Step query, including specific query control codes.
6
The Graphics and Simple Images in Results (GIR) option, Supplement for Trial Implementation
(http://www.ihe.net/Technical_Framework/upload/IHE_LAB_Suppl_GIR_Rev1-1_TI_2010-10_15.pdf)
page 2
In contrast, the APW profile utilizes the robust DICOM information object management capabilities for
persistent storage of imaging result objects (files). The DICOM infrastructure provides globally unique object
IDs, object organization and relationships supporting clinical tasks7, reliable transport within and between
institutions8, guaranteed archival storage, and on demand retrieval, all with a minimum of manual end-user
actions. Perhaps most appealing is that in many institutions an enterprise DICOM Picture Archiving and
Communication System (PACS) infrastructure is already in place, including policies and mechanisms for disaster
recovery and routine storage upgrades, which can be shared by pathology with the radiology and cardiology
departments. 9
To ensure interoperability, and to support clinically relevant store/query/retrieve tasks, DICOM rigorously
defines the types of objects exchanged (SOP Classes). It has a variety of native information objects, such as
photographic, X-ray and MR images, and allows encapsulation in a DICOM wrapper for specific externally
defined file types, including PDF and HL7 Clinical Document Architecture. To support lab result data files,
appropriate Encapsulated Document SOP Classes would need to be enumerated in the DICOM Standard.
Result files stored as DICOM objects would need to be reported to the LIS; an amendment of the GIR option to
allow DICOM references would be needed.
Integrated HL7 and DICOM Workflow
The integrated use of HL7 and DICOM is depicted in Figure 1 below. The LIS controls Work Order Steps among
all the lab devices, using HL7 messaging in accordance with the LAW and LDA Profiles. Devices producing result
files, such as a flow cytometer creating an FCS 3.1 file, write them to a shared file store, and pass a pointer to
the file in the OUL result message to the LIS. The LIS directs a WOS command to a file encapsulator application,
which reads the file, places it into a DICOM object, sends it to the PACS, and reports the unique object ID back
to the LIS for tracking purposes.
User interactive analytic applications, such as a flow cytometry analysis program, presumably are run on a
workstation with access to the LIS user interface for task management. The user can view the list of results
from analytic equipment, including their location on the shared file store and/or on the PACS. A result file may
be retrieved and further analysis performed, with the new results written to the shared file store, such as a
Gating-ML file describing the data gates used, or a PDF of cytometry dot plots and histograms. A notification of
those new result files is sent to the LIS. Again, the LIS directs the file encapsulator application to process the
files to the PACS.
7
DICOM objects are managed in an information hierarchy (think nested folders) of Patient / Study / Series / Object
8
DICOM protocol over TCP/IP (DICOM Part 8), Web Access to DICOM Objects (WADO – DICOM Part 18), Media exchange
(DICOM Part 10), and IHE Cross-enterprise Document Sharing for Imaging (XDS-I, in IHE Radiology Technical Framework).
9
Note that the massive amounts of data associated with whole slide imaging may make a radiology/pathology shared
PACS with WSI impractical. However, a shared PACS might easily accommodate other lab data flies, including flow
cytometry, while WSI is supported in a specialized PACS. Alternatively, a specialized WSI PACS for pathology might support
the ancillary smaller pathology files.
page 3
A variation on the file encapsulator could allow interactive processing of user managed data (i.e., outside the
automated workflow) for storage in the PACS. For example, images acquired by a digital camera may be
brought in on a memory chip; the JPEG images would be converted to DICOM standard visible light
photographic image objects under user selection or entry of appropriate demographic, study, and specimen
metadata from the LIS or other data sources. This mechanism could be used for gross specimen photography,
and for microscope field-of-view photography (camera on the head).
Of course, analytic equipment could send their result data directly in DICOM format to the PACS, such as whole
slide images.
WOS Control (HL7v2)
WOS Control (HL7v2)
Result notification
(HL7v2 pointer to DICOM object)
Result notification
(HL7v2 pointer to file share)
LIS
WOS Control (HL7v2)
Result file list
Result notification
(HL7v2 pointer to file share)
Result notification
Flow Cytometer
Camera
(grossing or
microscope)
Analysis software
WOS Control
(HL7v2)
Result notification
(HL7v2 pointer to
DICOM object)
Whole Slide
Imager
JPEG file
Gating ML
PDF dotplot
FCS file
Format TBD
File
share
File
share
Stainer
Gating ML
PDF dotplot
(FTP, NFS)
JPEG file
File
share
File encapsulator
File
share
FCS file (FTP, NFS)
WSI (DICOM)
Encapsulated FCS, Gating ML, PDF
Photographic image
(DICOM)
PACS
Figure 1 – Integrated HL7 and DICOM based workflow10
Code Sets for Lab Workflows
The capabilities described above create a technical architecture for workflow management in the lab,
applicable to a variety of uses and subspecialties. However, there is additional work required to effectuate
10
Visio source file for figure available on DICOM FTP server WG-26 folder (ftp://d9-workgrps:goimagego@
medical.nema.org/medical/private/dicom/WORKGRPS/WG26/LabWorkflow/).
page 4
clinical workflows for specific lab processes. Most important is the mapping of the desired clinical flow to steps
that can be managed or tracked by the LIS.
Each lab subspecialty requires definition of the coded vocabularies used in its process steps. This includes the
codes for the functions, tests, or analyses that the equipment can be commanded to perform, and the result
values that that can be produced. If the results are recorded in a file, there may need to be constraints on the
content of the file to ensure that it can be used by a receiver.
While individual lab organizations will often define their own set of codes, which then need to be configured
into the LIS and the lab equipment, some standardized code sets may be available for some processes. In
particular, LOINC is a major resource for standardized lab test and result codes. Sets of standard codes
specified by a professional specialty or in an IHE “content profile” can be pre-configured into lab systems,
reducing the cost of on-site configuration.
Orders and Results Workflow
The lab workflow sits inside the larger workflow of service level orders and results, i.e., the original order to the
lab, and the report(s) returned. This service level workflow is profiled in the APW Profile, and in the IHE-Lab
Laboratory Testing Workflow (LTW)11 and Inter-Laboratory Workflow (ILW)12 Profiles. In all three profiles, the
order is an HL7v2 OML message with ORL responses, and results are sent in an ORU message. The APW and
LTW Profiles allow the results to be sent to a different system than the ordering system; in the ILW Profile, the
metaphor is of a sub-contracted service, and the results are returned to the ordering system (the LIS in the
requesting lab).
The APW Profile further requires the LIS to forward the incoming order information to the PACS, allowing the
PACS to track archived evidence objects related to the order. (This transaction is not shown in Figure 1.)
The process in which the final lab result report is created is not profiled in the IHE-Lab or IHE-AP domains (it
may be an internal feature of the LIS). However, both domains have profiles for encoding lab results as HL7
CDA documents – the XD-LAB profile13, and the Anatomic Pathology Structured Report (APSR) Profile14.
Other Associated Workflows
Beyond the lab workflow there are a large number of related but separable workflows. These include use of
the report in patient care coordination; various data export flows (via CD or DVD media, by point-to-point
direct exchange, or through a Health Information Exchange); data import flows (mechanisms as with export,
11
IHE Lab Technical Framework Vol.1 Section 4 (http://www.ihe.net/Technical_Framework/index.cfm#laboratory)
12
Supplement for Trial Implementation (http://www.ihe.net/Technical_Framework/upload/
IHE_LAB_TF_Supplement_Inter-Laboratory-Workflow_ILW_TI_2009-07-16.pdf)
13
IHE Lab Technical Framework Vol.1 Section 9, and Vol. 3
(http://www.ihe.net/Technical_Framework/index.cfm#laboratory)
14
Supplement for Trial Implementation (http://www.ihe.net/Technical_Framework/upload/IHE_PAT_Suppl_APSR_Rev11_TI_2011_03_31.pdf)
page 5
but with the added function of merging patient information into local management identifiers); data
anonymization and collection for research and teaching; lab supply management; billing; and quality metrics
collection and quality improvement. While these are all important, they are out of scope for this discussion.
However, many of these workflows have been described in various IHE Profiles, especially in the IHE Radiology,
IT Infrastructure, and Patient Care Coordination domains.
Endorsements
This general approach to integrated lab workflow using HL7 for control and DICOM for result object
management has been discussed and approved by DICOM WG-26 Anatomic Pathology, DICOM WG-06 Base
Standard, HL7 Imaging Integration WG, the ad hoc group on Clinical Flow Cytometry Standards, and the ISAC
Standards Committee.
page 6