Skip to main content

Procedure Scheduled

AdvaPACS supports the IHE Procedure Scheduled [RAD-4] transaction for receiving new imaging orders and scheduled procedures via HL7 ORM messages. These messages allow an external scheduling system, such as a RIS or HIS, to create new orders and studies in AdvaPACS using the supplied patient, order, procedure, scheduling, and Study Instance UID information.

Supported Trigger Events

The following trigger events are supported by AdvaPACS:

Trigger EventAction
ORM^O01New imaging order / scheduled procedure.

Expected Actions

Order ControlAction
NWCreates a new order and associated study if a matching order cannot be found. Ignored if the order already exists.

Message Structure

Procedure Scheduled messages use the standard ORM^O01 message structure. The following segments are supported:

SegmentRequiredDescription
MSHYesIdentifies the message type, sender, receiver, and other message-level information.
PIDYesContains the patient identifiers and demographics.
PV1OptionalContains patient visit information, including the patient class and referring doctor where applicable.
ORCYesContains common order information, including the order control, order status, and order identifiers.
OBRYesContains the requested procedure and scheduled procedure step details, including the accession number, modality, and scheduled date and time.
ZDSOptionalContains the DICOM Study Instance UID associated with the scheduled procedure.

The following reference provides the supported fields for each HL7 segment used in this workflow. Unless otherwise stated, fields not listed are ignored during processing.

MSH

The MSH (Message Header) segment identifies the message type, sender, receiver, version and other information required to process an HL7 message. All patient registration messages sent to AdvaPACS must include a valid MSH segment.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
MSH-1Field Separator1STR-
MSH-2Encoding Characters4STR-
MSH-3Sending Application227HDR+-
MSH-4Sending Facility227HDR+-
MSH-5Receiving Application227HDR-
MSH-6Receiving Facility227HDR+-
MSH-7Date/Time of Message26TSR-
MSH-9Message Type15MSGR0076
MSH-10Message Control ID199STR-
MSH-11Processing ID3PTR0103
MSH-12Version ID60VIDR0104
MSH-15Accept Acknowledgment Type2IDO0155
MSH-16Application Acknowledgment Type2IDO0155

PID

The PID segment contains the patient identifiers and demographic information used to identify the patient associated with the report.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
PID-1Set ID - PID4SIO-
PID-3Patient Identifier List20CXR-
PID-5Patient Name48XPNR-
PID-7Date/Time of Birth26TSR2-
PID-8Sex1ISR0001
PID-13Phone Number - Home40XTNO-
PID-29Patient Death Date and Time26TSO-
PID-30Patient Death Indicator1IDO0136

Assigning Authorities

If the Assigning Authorities feature of AdvaPACS is enabled, Patient IDs must include Assigning Authority. The first subcomponent (namespace ID) of Assigning Authority shall be populated. If the second and third subcomponents (universal ID and universal ID type) are also populated, they shall reference the same entity as is referenced in the first subcomponent.

PV1

The PV1 (Patient Visit) segment describes the patient's encounter at the requesting facility. While many fields are optional for outpatient imaging, the segment can be used to communicate visit information, patient class, referring provider, and visit identifiers when available.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
PV1-1Set ID - PV14SIO-
PV1-2Patient Class1ISR0004
PV1-8Referring Doctor60XCNC0010
PV1-19Visit Number20CXC-

ORC

The ORC (Common Order) segment contains common order information used to identify and process the order. This includes the order control, order numbers, order status, scheduled date and time, and organisation information.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
ORC-1Order Control2IDR0119
ORC-2Placer Order Number22EIR2-
ORC-3Filler Order Number22EIR-
ORC-4Placer Group Number22EIO-
ORC-5Order Status2IDR0038
ORC-7Quantity/Timing200TQR-
ORC-10Entered By250XCNO0010
ORC-13Enterer's Location80PLR2-
ORC-17Entering Organization60CER2-

All (ORC, OBR) segment pairs sent in the Procedure Scheduled message shall be present in the Procedure Update message, not only the pairs introducing a change.

The following values are required when creating a new order:

  • ORC-1 — Order Control must be set to NW.
  • ORC-5 — Order Status must be set to SC.
  • ORC-7.4 — Quantity/Timing must contain the date and time of the Scheduled Procedure Step.

OBR

The OBR (Observation Request) segment contains information about the requested procedure and Scheduled Procedure Step associated with the order.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
OBR-1Set ID - OBR4SIR-
OBR-2Placer Order Number22EIR2-
OBR-3Filler Order Number22EIR-
OBR-4Universal Service ID200CER-
OBR-18Placer Field 160STR-
OBR-19Placer Field 260STR-
OBR-20Filler Field 160STR-
OBR-24Diagnostic Service Section ID10IDR0074
OBR-27Quantity/Timing200TQR-
OBR-34Technician200NDLO-

The following fields have specific uses within AdvaPACS:

FieldAdvaPACS ValueNotes
OBR-4Universal Service IDComponents 1–3 contain the Universal Service ID. Components 4–6 may contain the Scheduled Protocol Code.
OBR-15LateralityContains the procedure laterality when it is not already encoded in OBR-4.
OBR-18Accession NumberMust not exceed 16 characters.
OBR-19Requested Procedure IDAll OBR segments within the same message must contain the same Requested Procedure ID.
OBR-20Scheduled Procedure Step IDMultiple Scheduled Protocol Codes may reference the same Scheduled Procedure Step ID.
OBR-24DICOM ModalityContains the modality associated with the Scheduled Procedure Step.
OBR-44Requested Procedure CodeComponents 1–3 contain the Requested Procedure Code. Component 5 may optionally contain the Requested Procedure Description.

Note

The Placer Order Number and Filler Order Number provided in OBR-2 and OBR-3 must match the corresponding values in ORC-2 and ORC-3. Laterality may be included in the Universal Service ID in OBR-4. If it is not included, the laterality should be provided separately in OBR-15.

ZDS

The ZDS (Additional Identification Information) segment contains the DICOM Study Instance UID used to identify the study associated with the order.

FIELDNAMELENGTHDATA TYPEOPT.TABLE
ZDS-1Study Instance UID200RPR-

The Study Instance UID is provided in ZDS-1 using the following structure:

ComponentValue
ZDS-1.1DICOM-compliant Study Instance UID
ZDS-1.3Application
ZDS-1.4DICOM

Example Messages

The examples below illustrate typical HL7 messages used during order registration. Use them as a reference when building, testing, or troubleshooting your integration with AdvaPACS.

Create an Order

Use an ORM^O01 message to create a new order in AdvaPACS. For a new order, ORC-1 should be set to NW (New Order) and ORC-5 should contain the current order status. When the message is processed, the Patient will either be created or updated based on matching the Patient ID(s) provided in PID-3.

The following example creates a scheduled CT Chest order:

MSH|^~\&|RIS|HOSPITAL|ADVAPACS||20260706103000+1200||ORM^O01|MSG000001|P|2.5.1
PID|1||123456^^^HOSPITAL^MR||SMITH^JOHN^MICHAEL||19800115|M|||123 Example Street^^Auckland^^1010^NZ
PV1|1|O|||||1234^SMITH^JANE
ORC|NW|ORD123456|ORD123456||SC
OBR|1|ORD123456|ORD123456|CTCHEST^CT Chest^L||||||||||||1234^SMITH^JANE||ACC123456|RP123456|SPS123456||||CT|||^^^20260706120000

In this example:

  • PID-3 contains the Patient ID (123456).
  • ORC-1 is NW, indicating a new order.
  • ORC-2 contains the Placer Order Number (ORD123456).
  • ORC-3 contains the Filler Order Number (ORD123456).
  • ORC-5 is SC, indicating the order is scheduled.
  • OBR-4 contains the Universal Service Identifier, identifying the requested procedure as CTCHEST.
  • OBR-16 contains the Ordering Provider.
  • OBR-18 contains the Accession Number (ACC123456).
  • OBR-19 contains the Requested Procedure ID (RP123456).
  • OBR-20 contains the Scheduled Procedure Step ID (SPS123456).
  • OBR-24 contains the Diagnostic Service Section ID, in this case CT.
  • OBR-27.4 contains the scheduled date and time of the procedure (20260706120000).

Using Assigning Authorties

When Assigning Authorities are enabled, identifiers in the HL7 message should include the appropriate assigning authority. This allows identifiers from different systems or organisations to be uniquely identified within AdvaPACS. For example:

MSH|^~\&|RIS|HOSPITAL|ADVAPACS||20260706103000+1200||ORM^O01|MSG000001|P|2.5.1
PID|1||123456^^^HOSPITAL^MR||SMITH^JOHN^MICHAEL||19800115|M|||123 Example Street^^Auckland^^1010^NZ
PV1|1|O|||||1234^SMITH^JANE
ORC|NW|ORD123456^^HOSPITAL|ORD123456^^HOSPITAL||SC
OBR|1|ORD123456^^HOSPITAL|ORD123456^^HOSPITAL|CTCHEST^CT Chest^L||||||||||||1234^SMITH^JANE||ACC123456^^HOSPITAL|RP123456|SPS123456||||CT|||^^^20260706120000

The assigning authority provided for each identifier must match an Assigning Authority configured in AdvaPACS for the corresponding identifier type. Patient and order identifiers may use different assigning authorities depending on your configuration.

For more information regarding Assigning Authorities, refer to the Assigning Authority documenation.

Uploading a Document

Documents associated with an order, such as referral forms, consent forms, or other supporting documents, can be included in the HL7 message using an OBX segment. The document is provided using the ED (Encapsulated Data) data type and should be Base64 encoded.

The following example includes a PDF referral form:

MSH|^~\&|RIS|HOSPITAL|ADVAPACS||20260706103000+1200||ORM^O01|MSG000001|P|2.5.1
PID|1||123456^^^HOSPITAL^MR||SMITH^JOHN^MICHAEL||19800115|M|||123 Example Street^^Auckland^^1010^NZ
PV1|1|O|||||1234^SMITH^JANE
ORC|NW|ORD123456|ORD123456||SC
OBR|1|ORD123456|ORD123456|CTCHEST^CT Chest^L||||||||||||1234^SMITH^JANE||ACC123456|RP123456|SPS123456||||CT|||^^^20260706120000
OBX|1|ED|REDOC^Referral Form PDF||^ReferralSystem^application/pdf^PDF^Base64^JVBER...YWxvZw