Integrated Path Workflow

Also available as a Word document at File:IntegratedLabWorkflow 02.docx

IHE Anatomic Pathology Profile Proposal

• Proposed Profile Name: Integrated Path Lab Workflow
• Proposal Date: September 23, 2012
• Status: Proposed
• Version History: r02
• Editors:

Name	Affilliation	e-mail
Harry Solomon	GE Healthcare	harry.solomon@ge.com

1. Brief Description of 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.

2. Key Use Cases

Use Case 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 peri-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).

Use Case 2: Immunohistochemistry

Similar to solid tumor

3. Standards that might Apply

• HL7 v2.5.1
• DICOM
• CDA
• ebXML
• IHE Lab Device Automation (LDA) and Lab Analytic Workflow (LAW) Profiles
• IHE Anatomic Pathology Workflow (APW) Profile
• IHE Cross-Enterprise Document Exchange (XDS) Profile
• IHE Displayable Reports (DRPT) Profile

4. Further Discussion

4.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: [1]

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.

4.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 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.

4.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.

4.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) data , 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 can be managed in a system with a CDA repository.

4.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.

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.)

4.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 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).