IHE 2012-2013 Call for Proposals
IHE Brief Work Item Proposal
1. Proposed Work Item: Integrated Lab Workflow
Proposal Editor: Harry Solomon
Work item Editor: Harry Solomon
Date: September 23, 2012
Version: 02
Domain: Anatomic Pathology, with support from Laboratory
2. The Problem
There is a need for a comprehensive approach to pathology lab workflow that takes into
account the needs of both imaging lab equipment and clinical (chemistry) lab equipment
(which is also used in pathology). This workflow must be aligned with the needs of
clinicians, lab directors, and device and system manufacturers, including Laboratory
Information System manufacturers, for a unified approach to workflow management.
IHE AP has specified a departmental workflow (APW Profile) that leverages DICOM services
for worklist management. Results (images) are managed as DICOM objects by an Image
Manager/Archive, with references to that data handled in the LIS.
In contrast, IHE Lab has specified a departmental workflow (LAW Profile) that leverages
HL7v2 messages for workflow management and results. Results (including images) are
presumed to be managed directly by the LIS.
IHE AP has recognized the problem with proposals variously called “Device automation
integration profile”, or “Enhanced Imaging Workflow”, but those have not yet gained
consensus.
3. Key Use Case Storyboards
3.1 Solid tumor with whole slide imaging
[adapted from DICOM Part 17 Annex NN]
Preliminary activities (not part of this storyboard) – specimen and pathology order is received
in lab; specimen is accessioned into the LIS. Based on the order, LIS either retrieves, or
establishes local hyperlinks to, the patient medical history summary, the interventional
radiology or surgery report for the specimen collection procedure, the radiology or peri1
operative imaging, and other relevant clinical input. Retrieving such documentation may
require traversal of a health information exchange, but is out of scope of this use case.
The pathologist reviews the incoming clinical documentation and performs a gross
evaluation of the specimen, notes any findings into the LIS, and takes photographic images,
which are sent to the LabPACS. The pathologist determines that specimen tissue should be
analyzed further through histology, and directs a work order (through the LIS) to prep and
image the tissue in accordance with an appropriate histology protocol known by the LIS.
The lab technician processes the tissue with a fixative, places it into a labeled container
(cassette), and embeds the tissue in the cassette in a paraffin block; these manual steps,
including the fixation materials and process parameters, are logged into the LIS with the
cassette (block) identifier. From the block, a lab tech slices very thin sections (~5 μm, in
accordance with the protocol) on a microtome, and places the sections on slides and the
slides in a rack; these manual steps, including the slice thickness and spatial relationships of
the sections to each other and to the block, are logged into the LIS with the slide and rack
identifiers.
The lab tech may place slides from other cases that are following the same histology
protocol into the same rack.
The lab tech places the rack of slides into the slide stainer. The stainer reads the rack label,
and queries the LIS for the stain protocol to be used. The LIS responds with the protocol
(e.g., H&E), and the stainer executes the protocol. When done, the stainer reports the
status to the LIS with the specific parameters of the staining (including lot numbers).
The lab tech removes the rack of slides from the slide stainer and places it into the whole
slide scanner. The scanner takes each slide, reads the label, and queries the LIS for the
scanning protocol to be used. The LIS responds with the protocol (e.g., 40X RGB) and other
slide preparation attributes (specimen type, thickness, stain), and the scanner executes the
protocol. The whole slide images are stored in the LabPACS. When done, the scanner
reports the status to the LIS with the specific parameters of the imaging and references to
each slide’s image(s).
When the last step in the histology protocol is done, the LIS creates a technical summary
report for the pathologist, and makes the case data available for interpretation.
Post activities (not part of this storyboard) – Pathologist reviews all study information, creates
a clinical report (e.g., IHE APSR Profile). Report is returned to referring physician, either
directly or via HIE (XDR, XDS).
3.2 Immunohistochemistry
TBSL
3.3 Hematopathology with flow cytometry
May include automated specimen prep (de-cap, add reagent, mix, aliquot …)
Includes flow cytometry and cytometry raw results analysis by a separate actor
(workstation)
May include microscopic examination and field of view imaging
2
3.4 Pap smear with automated image analysis
TBSL
4. Standards
HL7 v2.5.1
DICOM
CDA
5. Systems
LIS – Order Filler / Automation Manager
Automated Stainers, Whole Slide Imagers, other lab devices – Acquisition Modality /
Laboratory Device / Analyzer
PACS – Image Manager / Image Archive
CDA Document Manager / Archive
6. Discussion
6.1 History
This topic has been discussed in IHE AP and IHE Lab, as well as in DICOM WG-26 (AP) and
WG-06 (Base Standard), and in the DICOM Standards Committee.
The proposal to use HL7v2-based workflow messaging rather than DICOM for images
acquired in a lab and stored in a DICOM PACS was discussed with DICOM WG-06 on October
26, 2011, and at a meeting of DICOM WG-26 on October 30, 2011. The latter meeting included
representatives of LIS, stainer, and imaging systems, as well as pathologists, with multiple
participants in each category. This proposed approach was approved by unanimous
consensus (although this specific document and its technical description were not). A
supporting presentation can be found at:
ftp://d9-workgrps:goimagego@medical.nema.org/medical/private/dicom/
WORKGRPS/WG26/2011/2011_10_30_San_Diego/Path_Workflow_Options.ppt
Aspects of the proposal were discussed in the DICOM Standards Committee on April 18,
2012. A recommendation from that meeting was to consider CDA as an alternative to DICOM
as the storage mechanism for bulk non-image data.
The proposal was further developed and discussed with IHE Lab in May 2012. As IHE Lab had
no experience with imaging or with bulk data storage (PACS), they decided to refer the issue
to IHE AP.
6.2 Scope
The scope of this work is similar to that of the IHE Lab LDA and LAW Profile; it focuses on
the interactions between the Automation Manager, the Laboratory Devices, and a persistent
object repository. It excludes the order coming into the department (which is handled in
3
other profiles). Also out of scope is the production of the clinical report, although ensuring
the evidence is accessible is in scope.
While the intention is to facilitate the use of HL7v2 messaging for lab imaging workflow, it
does not preclude the use of DICOM Modality Worklist and Performed Procedure Step
services for that functionality.
6.3 Alternative
An alternative approach would simply allow an actor to claim support for both the APW
Profile and the LAW Profile. However, the transactions of the LAW Profile do not support
the necessary segments and expected processing for handling laboratory analyses managed
as persistent information objects outside the LIS.
6.4 Data results
There are three classes of work products that need to be considered and managed in the
integrated workflow.
First, devices that natively produce discrete analysis results (observations) can report them
to the LIS in an HL7 OUL message, per the LAW Profile. These results should be saved in the
technical summarization report available to the reporting physician; they may or may not be
carried through to the final clinical report, as determined by the physician.
Second, devices that natively produce DICOM objects will store them directly to the Image
Manager / Image Archive, per the APW Profile. These objects will also be reported to the LIS
by reference in OUL messages (equivalent of reporting produced object references in an
MPPS message), and those references can be included in the technical summarization
report. The IM/IA supports subsequent access to that data.
A third class of data results are non-image bulk data objects that are not amenable to be
effectively conveyed in discrete observations, but which are not native DICOM objects. Such
objects may include staining procedure step reports, flow cytometry list mode (FCS) data1,
and other intermediate analyses and evidence. All these objects require persistent data
storage and access, and a preferred format may be CDA (with either an encapsulated
nonXMLBody, or a native structuredBody) so that they they can be managed in a system
with a CDA repository.
6.5 Technical approach
The approach is based on adding a variant of the IHE Lab LAW Profile transactions to the
APW Profile. It also has elements of a content profile to ensure end-to-end effectiveness of
the pathology lab imaging use case.
As in the LDA/LAW Profiles, Work Order Step management is controlled through HL7v2
messages. Imaging steps may be controlled through DICOM MWL/MPPS. As an
implementation strategy, a broker may mediate transformation of HL7v2 to/from DICOM, or
the LIS could support DICOM natively. This requires full equivalence mapping between the
HL7v2 and DICOM messages.
1
Note that there is discussion of creating a DICOM object for FCS data.
4
Imaging work products, can be stored and storage committed to the Image Manager /
Image Archive, as in the current APW Profile. The Acquisition Modality actor that produces
the DICOM objects may be implemented as a workstation that DICOM-izes images from a
generic imaging device (camera), or encapsulates other file formats (e.g., PDF) in DICOM
instances. References to those stored objects are sent to the LIS.
Analytic work products may also be sent to the LIS in HL7v2 messages (as Encapsulated
Documents or as Reference Pointers). As Encapsulated Documents, the LIS is responsible
for their storage and later access. As Reference Pointers, we will need a mechanism by
which the LIS can determine whether the RP is to an object already persistently stored, or
whether it needs to take control of management (possibly using the OBX-28 Process Control
data element being defined in v2.8).
A CDA repository is an alternative mechanism to a DICOM Image Archive for persistent bulk
data storage. Such a CDA repository actor could be implemented by the LIS, or by a PACS, or
by a separate repository system implementation. The analytic device may send CDA objects
directly to the repository, or the LIS may manage that storage operation. Again, references
to those stored objects are managed in the LIS.
At the conclusion of the work order processing, the LIS should produce a summarization of
all the technical process steps performed and all the relevant technical results in an HL7
message or in a CDA document that can be later accessed during the reporting (professional
interpretation) process. (This is equivalent to the lab results ORU or OUL in accordance with
LAB-3 transaction.)
6.5 Open Issues
1. The big issue is which of the alternative workflow and storage alternatives are
mandatory and which optional, and how to specify the optionality. If we define a
separate broker actor, the LIS can be purely HL7, and brokers can become official
IHE actor participants (rather than needing to be bundled with a particular
DSS/OF). On the other hand, if we mandate the LIS to support DICOM, each LIS
manufacturer is responsible for broker integration.
2. HL7 Change Proposal 726 adds the IPC segment to the OML messages to allow
control of DICOM imaging in an HL7 workflow. As this will not be effective until
v2.9, the transactions will need to “pre-adopt” this change.
3. DICOM Supplement 122 included the Specimen Preparation Sequence to pass
critical parameters of the slide to the scanner, such as specimen thickness and
stain. It is possible to pass such data in the HL7v2 OML message, but the profile
will need to address the “content” of that data, and its mapping into the
Specimen Preparation Sequence of the DICOM WSI header.
4. An advantage of DICOM as a storage mechanism is that it specifies standard
mechanisms for department/intra-institutional access (DICOM Query/Retrieve)
and export (IHE PDI/XDS-I Profiles). Do we need to require the CDA repository to
provide standard mechanisms for access and/or export (e.g., RID and XDR/XDM
Profiles)? [Compare the IHE Cardiology Displayable Reports (DRPT) Profile
5
requirements for Report Repository to be grouped with the Information Source
actor of the ITI Retrieve Information for Display Profile.]
5. In IHE, two mechanisms have been profiled for CDA submission to a repository –
the Provide and Register transaction in XDS/XDR, and an HL7v2 MDM mechanism
in DRPT. We should select one.
6. Need to determine the extent of “content specification” to be included in
profiling of work products, in order to scope the necessary requirements on
repositories (IM/IA and CDA).
6