[randomh3r0]

It also goes well beyond just talking about the imagery itself or the metadata surrounding it, and the standard contains its own network protocol effectively for transmitting data between PACS systems and other endpoints. (I recently worked in medical imaging for over 6 years and know DICOM fairly well, warts and all).

That said, there are absolutely better ways of handling almost any of the cases DICOM supports, the issue is that there is almost no standard that is fully backwards compatible which supports everything DICOM does, so we're sorta shackled to it for better or worse. Otherwise you have to deal with trying to explain to underfunded clinics (not the Mayo or Cleveland type) around the world why their expensive machine that they bought second or third hand is no longer acceptable.

[specialist]

In your professional opinion:

Is there any need or demand for a decent Java language DICOM parsing library?

Mid-aughts, I wrote a DICOM image viewing applet. (Before tile-servers a la Google Maps, which would have been a better strategy.) My library could read DICOM filestores. But not do network interchange.

DICOM applet was intended to be part of our EMR web client, our frontend to showcase our portable electronic medical records backend stuff. At the time, it was an amazing demo, greatly helping our Sales team.

My code (IP) got lost, abandoned. (Acquisition, abandonment, high mgmt turnover, etc. Typical M&A story.) So sad. Anyone who'd know or remember what my code did is long gone.

--

Ditto my HL7 2.x and 3.x libraries, FWIW. I wrote my stuff in response to the available tools at the time. SeeBeyond ICAN/JCAPS, Mirth, BizTalk, a bunch of others I now forget. Turrible. I'm out of the field, so I imagine the world's moved on. FHIR and whatnot.

[randomh3r0]

We lived predominantly in the .NET world and leveraged Fellow Oak Dicom pretty heavily, but when I did have to use anything in Java-land we pretty much always leveraged dcm4che, as it did what we needed and we didn't need to monkey with it much. Ultimately given my ignorance of that ecosystem I'd be hard pressed to advise about the need or demand in Java one way or the other unfortunately. Sorry about that!

You made me shudder by mentioning BizTalk just now, though. I had long since shut that way in the corners of my mind.

[specialist]

Thanks for the feedback.

Ya, with all the ETL work I've done, I've been cured of any interest in visual programming, "no-code", and the latest iteration of CASE tools in general.

Aside from all the BizTalk specific heartache...

With patch-cord programming, you always have to drop down to actual code for that last 5% of work, the fit & finish. Then you're fighting the framework (tool).

Better to have an API that's easy and bulletproof. My solution for HL7 "interface" implementations was to ingest the specifications (authored by our customer facing business analysts) and output Java source code. Then use any IDE (tool stack) to proceed as normal for that last 5%.

We'd onboard new teammates (to do "HL7 interfaces"), most who had never seen Java before, in about 2 weeks. At the time, the assumption was onboarding to ICAN (or equiv) would take about 3 months. (Yikes.)

I was always interested in playing with C# and LINQ for our work. But none those sales leads panned out.

[thfuran]

>Is there any need or demand for a decent Java language DICOM parsing library?

Dcm4che is that, though perhaps there could be some debate as to whether it's decent. I don't know; I'm stuck using quite an old version.