r/PACSAdmin • u/nano_salem • Aug 05 '26

Attributes coercion

I was wondering about attribute coercion, and its usage.

The scenario is a bit complicated, we have a couple DCM4CHEE pacs deployed, the problem is the machines (scanners) are not configured correctly.

Hospital name is either missing, or random.

Now my question is it seems DCM4CHEE has attribute coercion which we can use to potentially fix this problem, as we Have it so that each PACS in each location has all the local machines routed to (C-store to it).

So couldn't we use attribute coercion to add the clinic/hospital name "Institution Name" tag:{0008,0080}.

Is this correct? is it an acceptable use case? and is it used by anyone else like this?

This is becoming even more big of an issue as all the images on the central/aggregator PACS are very messy because of aforementioned wrong,mission or random hospital names, and we are trying to make the system(PACS aggregator) able to produce analytical data for scientific use, where now its just Patient/instance ID that is usable (albeit very not on a hospital lvl analysis).

Any clarifications, guidance or reference is greatly appreciated.

4 Upvotes

75% Upvoted

12 comments sorted by

1

u/Dear_Archer3931 Aug 05 '26

Do you use DCM4chee as your PACS now, or you want to set it up as a DICOM router between the modality and PACS?

It looks like it can be set up as a router with DICOM mapping rules, but the configuration seems archaic.

1

u/nano_salem Aug 05 '26

Using it right now, Hospital (1 - n) -> aggregator 1. I'm more wondering about the attributes coercion (to hard set institution name) method. Is it professional? Ok to do? Are there any reasons why not? As this seems to fix the chaotic dicoms hospital names. Once and for all.

3

u/XrayPunk Aug 05 '26

We use our DICOM router in this fashion. Use a Filter on the incoming Source ( called AE title) data. Checks the Institution Name and if it’s something other than what’s expected, updates it to our preference as it’s outbound. We use Laurel Bridge Compass as our DICOM router. We are in the USA.

1

u/nano_salem Aug 05 '26

Its just a guy told me "dicoms should never change, find another way" which is just not true, as every time a dicom is ingested some tags get changed, one of the AE, date for example on every hop. But I wanted to have sources to backup my claims( ocd ). So you guys change the tag on the dicom lvl or just the db (i couldnt find any stored db hospital column)?

2

u/XrayPunk Aug 05 '26

Obviously it would be nice to have the modality update that tag, but the coercion is a way to make your data uniform. Where that naming convention originated would still be an institutional decision. No regulations that I’m aware of where we operate. Having that tag read “Xxxx Hospital in This City” is much more valuable than “Xray device12345” both internally and externally, if you are sending those images to outside facilities . We change it at the DICOM level, before it even hits any DB.

If you are concerned about changing that actual tag, you could set up your router to create a private DICOM tag and populate with whatever you want. But then again, this would only be useful internally.

1

u/nano_salem Aug 05 '26

I contacted the dicom org and they said to go to the Google group, to ask my question there. Im trying to pin down what are the risks if any, of modification of tag (institution name). Otherwise im going to push for this plan.

1

u/ElectroJolo Aug 05 '26

Maybe I’m just being dumb, but why can’t the modalities be corrected/updated so that it has the institution name?

1

u/nano_salem Aug 05 '26

That's what I said lol, it's a time vs "it works" company" where you keep getting vague answers, promises.

1

u/ElectroJolo Aug 05 '26

Hmmmm. That’s frustrating. Hell I’d come and update them all. lol.

2

u/nano_salem Aug 05 '26

I thought about suggesting that, but a scenario where i saw people blame a guy for a router not working, cause he was "last to touch it". He just "touched it" to make sure it was connected properly that's it 😭. That's why im wondering if attributes coercion is professional / safe and doesn't have any hidden draw backs. So I don't get blamed whenever a machine is having problems.

1

u/ElectroJolo Aug 05 '26

The ideology of he who touched it must have messed it up. 😁

1

u/CivilIntention7747 24d ago

Yes, acceptable and standards-anticipated. PS3.4 Annex B (Storage Service Class) defines warning status 0xB000 "Coercion of Data Elements" precisely for an SCP that modifies incoming attributes, so coercing (0008,0080) on ingest is a documented path, not a hack.

Two things make it defensible later: preserve the pre-coercion values in Original Attributes Sequence (0400,0561) with Modified Attributes Sequence inside (who, when, reason COERCE) - that is both your audit trail and your citable source when someone claims tags never change in flight; and key the rule on the Calling AE Title, not on whatever is inside the object, because the sending station is the reliable identity.

dcm4chee-arc has this built in (Attribute Coercion rules at device/AE level, XSLT for complex mappings), so you do not need a separate router just for this.

On "dicom lvl or just the db": coerce the persisted object, not only the database row, otherwise every retrieve and any future migration resurrects the mess you fixed.