The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

IPC - Imaging Procedure Control Segment

The IPC segment contains information about tasks that need to be performed in order to fulfill the request for imaging service. The information includes location, type and instance identification of equipment (acquisition modality) and stages (procedure steps).

Note:     References, field names and definitions in this section were developed in collaboration with DICOM with the goal of keeping HL7 transmission of imaging procedure control information consistent with the DICOM Standard, available at http://medical.nema.org.


HL7 Attribute Table - IPC - Imaging Procedure Control Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
IPC
1 01330 Accession Identifier SHALL [1..1] EI
2 01658 Requested Procedure ID SHALL [1..1] EI
3 01659 Study Instance UID SHALL [1..1] EI
4 01660 Scheduled Procedure Step ID SHALL [1..1] EI
5 01661 Modality [0..1] CWE
6 01662 Protocol Code [0..*] CWE
7 01663 Scheduled Station Name [0..1] EI
8 01664 Scheduled Procedure Step Location [0..*] CWE
9 01665 Scheduled Station AE Title = [0..1] 16 ST
10 00816 Action Code [0..1] [2..2] ID

IPC-1: Accession Identifier (EI) 01330

(Definition from IPC.1 in Ch. 4)

Definition: A workflow-management IDIS generated number that identifies the Filler Order for an Imaging Service (Imaging Service Request). This identifier corresponds one-to-one to the Order Filler number but is used in internal tracking of the work by the IDIS and in communication between IDIS within the department. It also has specific requirements to assure its compatibility with DICOM. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Imaging Service Request. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0008,0050) that conveys information identical to the component one of this field.

An IDIS that performs functions of the workflow management for a department may accept a single Placer Order that gives rise to one or more Filler Orders-Imaging Service Requests. For example, an IDIS may receive an order for an X-ray examination of the patient daily at 8 am for the next three days. For the purposes of fulfilling the Placer Order, it will identify each of the daily exams either as a separate Filler Order or parts of a single Filler Order. Correspondingly, it will assign one or more Filler Order numbers associated with the order. For each of the Filler Order numbers, it will assign a unique Accession Number.

Each of the Imaging Service Requests may contain one or more Requested Procedures that it will identify with the Requested Procedure ID. The Requested Procedure is the most granular unit of work that may lead to the creation of the procedure report. Each procedure report contributes to the results for the order. In the example mentioned above, each of the daily examinations will require a separate diagnostic report, hence each of them will be treated as a separate Requested Procedure. Depending on the treatment of the order by the IDIS, it will either link all Requested Procedures to a single Filler Order-Imaging Service Request, or link each Requested Procedure to its own Imaging Service Request. Exact type of requested procedure is conveyed by the coded values in OBR-44 Procedure Code and OBR-45 Procedure Code modifier for each procedure. Note that in case of multiple Requested Procedures corresponding to one order, each procedure may have different code.

To support communication with the instances of equipment in a department (acquisition modalities), IDIS will also generate the Study Instance UID, a globally unique identifier for each Requested Procedure. This identifier will be used by acquisition modalities to identify all generated images and other DICOM objects related to this Requested Procedure. Note that, unlike the Study Instance UID, the Requested Procedure ID must only be unique within the scope of the encompassing Imaging Service Request identified by an Accession Number.

Each of the Requested Procedures may be further broken down by the IDIS into the Scheduled Procedure Steps based on the timing and equipment requirements. Each step is identified with the Scheduled Procedure Step ID. A single Procedure Step may only be performed on a single type and instance of the equipment. Thus, while the Requested Procedure may identify multi-modality examination (such as ones common in Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on a single modality.

The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step is depicted in a figure 4-6. Identifiers of the entities are represented by the field names stated in square brackets.

Figure 4-6. Hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step

The full hierarchy constitutes the context that will be shared between all IDIS within a department in a course of order fulfillment.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. A pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. Value of the IPC-1 field shall be identical in all IPC segments.

Considering the preceding example of X-ray examinations on subsequent days with two different steps identified for the last Requested Procedure and examinations to be performed at the site, "RADIOLOGY", the communication of the information using OMI message may look like the following:

MSH|...<cr>

PID|...<cr>

ORC|NW|...<cr>

OBR|1|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>

IPC|A345^RIS|P1234^RIS|1.2.840.1234567890.3456786.1^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

ORC|NW|...<cr>

OBR|2|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>

IPC|A345^RIS|P1235^RIS|1.2.840.1234567890.3456786.2^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

ORC|NW|...<cr>

OBR|3|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPALAT^X-Ray Chest PA and Lateral|...<cr>

IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS2^RIS|CR|SXLAT^Chest Lat||RADIOLOGY|<cr>

(Definition from SAC.2 in Ch. 13)

Definition: This field identifies the laboratory accession (see section 13.2.3, "Glossary"). This identifier is assigned by the information system of the laboratory performing the tests.

An accession identifier can refer to more than one container. A Container Identifier (see below) is a Unique Identifier for that container.

IPC-2: Requested Procedure ID (EI) 01658

Definition: This field is the identifier of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for the imaging service. It is a case of the Entity Identifier data type (section 2.A.28). The first component of this field is a string that identifies the Requested Procedure. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Requested Procedure within the scope of the order (as specified by accession number). This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0001) that conveys information identical to the component one of this field.

The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.

A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may involve one or more pieces of equipment.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-2 field shall be identical in all IPC segments related to the same Requested Procedure.

IPC-3: Study Instance UID (EI) 01659

Definition: Globally unique identifier assigned by the workflow management IDIS to the Imaging Study under which all images and other DICOM objects produced in the course of the Requested Procedure shall be collected. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Study. A limit of sixty-four (64) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0020,000D) that conveys information identical to component one of this field. The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Study Instance UID always identifies the actual filler of an order.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-3 field shall be identical in all IPC segments related to the same Requested Procedure.

IPC-4: Scheduled Procedure Step ID (EI) 01660

Definition: This field is the identifier of a particular Procedure Step (sub-procedure) of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for imaging service. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Procedure Step. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Procedure Step within the scope of the Requested Procedure. This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0009) that conveys information identical to the component one of this field.

The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.

A Procedure Step is an arbitrarily defined scheduled unit of service, which is specified by the Procedure Plan for a Requested Procedure. A Procedure Step prescribes Protocol that may be identified by one or more protocol codes. A Procedure Step involves equipment (e.g., imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g., start time, stop time, duration). While in the context of Imaging Service request the scheduling of a Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Procedure Step involves one and only one piece of imaging Modality equipment.

IPC-5: Modality (CWE) 01661

Definition: The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure.

This field is a case of the CE data type. Refer to External Table 0910 – Acquisition Modality in Chapter 2C, Code Tables, for valid values, and to DICOM Standard Part 3 for further details on DICOM Attribute (0008,0060) that conveys information identical to component one of this field.

A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM. The third component of this field, if present, shall have the value of "DCM" (see HL7 Table 0396 – Coding Systems in Chapter 2C, Code Tables).

IPC-6: Protocol Code (CWE) 01662

Definition: One or more coded entries identifying the protocol according to which the Scheduled Procedure Step shall be performed. Protocol Code(s) may identify particular equipment settings as well as operator's manipulations. Refer to Table 0605 - Protocol Code in Chapter 2C for valid values.

A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol that may be conveyed by one or more Protocol Codes. Typically, the code or codes identifying Protocol instance would be selected from a catalog of protocols established locally or provided by equipment manufacturers or professional organizations. Multiple Protocols may not exist in one Scheduled Procedure Step. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0008) that conveys information identical to components one through three of this field.

A limit of sixteen (16) characters for the first component and sixty-four (64) characters for the second component is required to allow compatibility with DICOM.

IPC-7: Scheduled Station Name (EI) 01663

Definition: This field identifies the instance of the modality resource being requested for the performance of a particular Scheduled Procedure Step. It is a case of the Entity Identifier data type (section 2.A.28). The first component of this field is a string that identifies the particular piece of equipment. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0010) that conveys information identical to the component one of this field.

The second through fourth components identify the organization, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator").

If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.5.6.8, "IPC-8 Scheduled Procedure Step Location (CWE) 01664," for explanation of the resource pool.

IPC-8: Scheduled Procedure Step Location (CWE) 01664

Definition: This field specifies a locally defined physical location of the modality resource being requested for performance of particular Scheduled Procedure Step. Although location is usually defined geographically (such as identification of a campus, building, floor, etc.) it may be used for identification of a pool of equipment (resources) formed by any other means. Values for the field shall be drawn from a locally defined coding scheme. Refer to Table 0606 - Scheduled Procedure Step Location in Chapter 2C for valid values.

For example, the pool may be defined as a set of three CT scanners belonging to an imaging center within a hospital. Two of these scanners may also be grouped into another pool based on their location at a building A, whereas the third scanner may be in a pool by itself due to its location in a building B.

If this field contains more than one location code, the equipment may be drawn from several resource pools.

If this field is empty and the fields IPC-7 and IPC-9 are also empty, it is assumed that a particular Procedure Step may be performed by any instance of equipment of a particular type within an organization.

See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0011) that conveys information identical to component one of this field. A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM.

IPC-9: Scheduled Station AE Title (ST) 01665

Definition: This field contains the Application Entity Title of the modality resource being requested for performance of a particular Scheduled Procedure Step. Application Entity Title is the identifier that identifies an instance of DICOM-compatible equipment for the purpose of addressing during communication. See DICOM Standard, Part 3 for further details on the DICOM Attribute (0040,0001) that conveys equivalent information. A limit of sixteen (16) characters is required to allow compatibility with DICOM.

If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.5.6.8 for explanation of the resource pool.

IPC-10: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.