HL7 ORMO01 XO is less lenient than dcm4chee 2.x

[fonteneu]

In upgrading from 2.x to arc light we encounter numerous problems with HL7 ORM01 not being lenient enough for our use case

We have worked around most, but two points remain.

1. ORDER CREATION:

There is a HL7 job (external tool) that periodically queries a customer database for worklist items.

For each entry, we used to send ORM^01 with "XO" to dcm4chee 2.x

This both created and updated the worklist entries perfectly.

The external HL7 job has no knowledge if a worklist entry is sent before or not so this was really nice.

Now with dcm4chee arc light, we have to provide both ORC.1.1 and ORC.5.1

However, if we use "XO" as before for both creation and updates, dcm4chee complains. It seems it requires "NW" for the first call and then "XO" after than.

2. MPPS:

We use MPPS to update status from SCHEDULED to COMPLETED. I worry that the periodic HL7 job sending ORC.5.1 with "SC" will reset this back to SCHEDULED.

Is there a way to recover the lenient 2.x functionality through settings ?

[vrindanayak]

Now with dcm4chee arc light, we have to provide both ORC.1.1 and ORC.5.1

This is a requirement in IHE - RAD-4. Default configuration currently supports NW / SC or NW / IP or XO / SC in ORC.1 / ORC.5 fields. What is the combination for these two fields in your HL7 messages?

We use MPPS to update status from SCHEDULED to COMPLETED. I worry that the periodic HL7 job sending ORC.5.1 with "SC" will reset this back to SCHEDULED.

There is no auto update of MPPS status on receive of MWL

[fonteneu]

What is the combination for these two fields in your HL7 messages?

For the dcm4chee 2.x solution, only "XO" was used alone and it worked great.

As mentioned, the HL7 processor have no information about if a HL7 message is sent before or not. That's why it was great that XO both created and updated.

For arc light, we're not sure what to do then. We can't really use NW in the HL7 processor since it doesn't know if it's the first time or not. It just periodically asks a customer's database for worklist items and then sends HL7 to dcm4chee. It has not state to know if it's create or update.

There is no auto update of MPPS status on receive of MWL

Thanks, this is great

[vrindanayak]

As mentioned, the HL7 processor have no information about if a HL7 message is sent before or not. That's why it was great that XO both created and updated.
For arc light, we're not sure what to do then. We can't really use NW in the HL7 processor since it doesn't know if it's the first time or not. It just periodically asks a customer's database for worklist items and then sends HL7 to dcm4chee. It has not state to know if it's create or update.

What were the MWL SPS Statuses before? When you say XO itself updated the MWL, are you referring to MWL attributes update other than SPS Status?

[fonteneu]

The HL7 server sends a full ORMO01 for every scheduled appointment, periodically, and it only ever uses XO.

dcm4chee 2.x will then create the MWL item if missing. If it exists it will update time, date, etc if that has changed since last time the HL7 ORMO01 XO was sent for the accession number.

[vrindanayak]

What about the Scheduled Procedure Step Status of MWL itself? - SCHEDULED / COMPLETED / CANCELED....

[fonteneu]

Modalities call MPPS to set SCHEDULED -> INPROGRESS -> COMPLETED

The HL7 messages seems to never affect this, which is good

All we want is for HL7 ORMO01 XO to create and update MWL items, then MPPS is used for status

[vrindanayak]

The HL7 messages seems to never affect this, which is good

Scheduled Procedure Step Status is required as per IHE RAD-4 / RAD-13. See

• https://dicom.nema.org/medical/dicom/current/output/html/part04.html#sect_K.6.1.2.2
• https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf#page=216

All we want is for HL7 ORMO01 XO to create and update MWL items, then MPPS is used for status

What was the value for Scheduled Procedure Step Status for MWLs in dcm4chee archive 2.x when HL7 messages were always being sent with XO?

[fonteneu]

0040,0020 becomes an empty string, which when queried implies SCHEDULED

Modalities then at a later point send status updates. Any HL7 ORMO01 XO messages in the mean time or in the future do not affect what MPPS has set, which is good

[vrindanayak]

0040,0020 becomes an empty string, which when queried implies SCHEDULED

Not clear what you mean here - How did you query? This attribute is not present on root level! - It is present inside Scheduled Procedure Step Sequence
I had meant what do you see in the MWL attributes or MWL C-FIND response (on requesting back complete Scheduled Procedure Step Sequence)?

[fonteneu]

I checked. It's empty, 00400020 CS=0, until a modality MPPS sets it to IN PROGRESS

I guess modalities think missing/empty value means it's SCHEDULED as a default value

[vrindanayak]

It's empty, 00400020 CS=0, until a modality MPPS sets it to IN PROGRESS

It is strange, as MWL SPS Status has no support for IN PROGRESS. In Dcm4chee Archive 5.x, if MPPS is IN PROGRESS, MWL SPS status is set to STARTED.

You may workaround by

• Customize the default hl7-order2dcm.xsl stylesheet to handle the invalid ORC.1 values and always set the state to SCHEDULED for this tag.
• Rename the stylesheet to f.e. hl7-order2dcm-myorg.xsl and update Vendor Data
• Update HL7 Schedule Procedure Template URI to reflect your customized xsl
• Reload the config (if required)

Note : However, by having the MWL SPS status always to SCHEDULED and not changing its state to COMPLETED / CANCELED / DISCONTINUED will mean :

• These MWLs will always be present in DB and returned in C-FIND responses back to modalities even when the procedure is completed or canceled on the modality side.
• You may optionally choose to set the MWL SPS status to COMPLETED on receive of studies (referencing the MWL) by configuring https://github.com/dcm4che/dcm4chee-arc-light/wiki/Update-MWL-status-to-COMPLETED-for-received-studies
• To auto delete piled up COMPLETED MWLs, you may additionally configure Delete MWL Delay(s) and MWL Polling Interval

[fonteneu]

Thanks for the information, this is very helpful.

The whole HL7 interface seems so fragile and complicated that we think about using the REST instead to create and update MWL items. Is this a route you can recommend?

[vrindanayak]

The whole HL7 interface seems so fragile and complicated that we think about using the REST instead to create and update MWL items. Is this a route you can recommend?

Yes, you can refer MWL-RS REST APIs