Digital Pathology Ordering & Workflow (DPOW)
0.1.0-current - ci-build
Digital Pathology Ordering & Workflow (DPOW)
0.1.0-current - ci-build
Digital Pathology Ordering & Workflow (DPOW), published by IHE Pathology and Laboratory Medicine Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.1.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/PaLM.DPOW/ and changes regularly. See the Directory of published versions
This section corresponds to transaction [LAB-101] of the IHE PaLM Technical Framework. Transaction [LAB-101] is used by the Physical Asset Workflow Manager (PAWM) and Digital Asset Workflow Manager (DAWM) actors. It is initiated using OML^O21 and acknowledged with ORL^O22; common segment definitions are specified in the Volume 2 Appendices.
Editor's note: The section number
3.LAB-101uses the provisional transaction number as its section identifier pending formal IHE transaction number registration.
This transaction is used by either the PAWM or the DAWM to send case-level updates to the other actor - any case-level data or metadata the two systems need to keep synchronised throughout the diagnostic process. Case status and workflow-state updates (conveyed via ORC-5 / ORC-25) are the principal example, but the transaction also carries other case-level information such as pathologist assignment, case-level comments, and other order/exam-level fields.
Table 2:3.LAB-101.2-1: Actor Roles
| Actor | Role |
|---|---|
| Physical Asset Workflow Manager (PAWM) | Initiates and receives case-level updates, e.g., case registration and examination progress/completion. |
| Digital Asset Workflow Manager (DAWM) | Initiates and receives case-level updates, e.g., case sub-status changes (draft, preliminary, final, ended). |
Rationale for bidirectionality: in deployments where both a PACS (as DAWM) and a LIS (as PAWM) independently hold case-level state, neither is purely subordinate to the other. Both directions are required for synchronisation.
The process flow for this transaction is illustrated in Volume 1, Use Case #4 (Case Update).
NW) and examination progress/completion (SC + IP, then SC + CM), e.g., grossing complete, all images imported.The message is OML^O21. MSH-21 SHALL be populated with DPOW-CASE-UPDATE^IHE.
The message carries case-level data and metadata in general. Its principal use is conveying case status; other case-level information (e.g., pathologist assignment via PRT, case-level comments via NTE) MAY also be included in the same message.
ORC-1 SHALL carry the Order Control code: NW for the initial case registration, SC (Status Changed) or XO (Change Order/service request) for subsequent updates. ORC-5 SHALL carry the high-level order status (HL7 Table 0038), e.g., IP (in progress) or CM (completed). ORC-25 (Order Status Modifier) MAY carry a case sub-status drawn from the DPOW Case Status value set (codes defined in the DPOW Case Status code system): Draft, Preliminary, ForTranscription, Final, or Ended. The ORC-1 / ORC-5 / ORC-25 combinations are illustrative and other combinations are possible. Physical and imaging milestones (e.g., grossing complete, all images imported) are typically conveyed as SC + IP updates, optionally with an NTE free-text note. The flow is illustrated in Volume 1, Use Case #4.
Open Issue 10: The DPOW Case Status value set is a working draft (ECDP 2026, 16/06/2026); it requires formal PaLM TC review and OID registration before Trial Implementation. See Significant Changes and Issues.
Field mapping. Fields this transaction populates (full segment definitions in the Volume 2 Appendices, Appendix A):
| Concept | HL7 Field (v2.5.1) | Usage | Example | Notes |
|---|---|---|---|---|
| Patient ID | PID-3 | R | 1234567890 | |
| Order control | ORC-1 | R | NW / SC | NW = new case; SC = status change |
| Case status | ORC-5 | R | IP / CM | HL7 Table 0038 |
| Case sub-status | ORC-25 | RE | Final^Final | Order Status Modifier; DPOW Case Status value set (dpow-case-status) |
| Case / order number | OBR-2 / OBR-3 | R | A4486 / B23-17890 | case identifier |
The receiving actor SHALL update its internal case record to reflect the received case-level data, including the case status conveyed in ORC-5 / ORC-25 when present. The receiving actor then returns the ORL^O22 acknowledgement described below.
OML^O21 Case Update message by the receiving actor.The receiving actor returns ORL^O22 as the application acknowledgement. MSA-1 conveys the acknowledgement code: AA (accept), AE (application error), or AR (application reject). When MSA-1 is AE or AR, an ERR segment SHOULD convey the error detail.
Validation required - see WI-DPOW-01. The exact MSA/ERR usage is subject to message validation before Trial Implementation.
The initiating actor SHALL process the acknowledgement. On AE/AR it SHOULD log the failure and MAY retransmit the update.
Not applicable. DPOW is an HL7 v2.5.1 messaging profile and defines no FHIR CapabilityStatements; actor conformance is defined by the HL7 v2 message and segment specifications above and in the Volume 2 Appendices.
This transaction conveys PHI. All actors SHOULD be grouped with ATNA and the Consistent Time (CT) Time Client (see Volume 1, Section 1:XX.5).
Because [LAB-101] is bidirectional, either actor may be the sender or the receiver for a given message.
When grouped with an ATNA Secure Node or Secure Application, the sending actor SHALL record an audit event when it sends a [LAB-101] message.
When grouped with an ATNA Secure Node or Secure Application, the receiving actor SHALL record an audit event when it receives a [LAB-101] message.
IG © 2026+ IHE Pathology and Laboratory Medicine Technical Committee. Package ihe.palm.dpow#0.1.0-current based on FHIR 4.0.1. Generated 2026-09-23
Links: Table of Contents |
QA Report
Version History |
|
Propose a change