Thursday, November 1, 2018

HL7Kit 2018 - Integrated DICOM and HL7 Solution

Yo! It's been a while ... no posts since June 2016 :-§

Maybe its because when you do there's less time to talk, ah? Anyway, I finally got some time for it and that's because HRZ have finally officially released HL7Kit 2018. Yeah! Check this beautiful little web site we've published for the occasion. Let me tell you about this product that my team and I worked so hard to push through the door.

For those of you that worked with the kit before, the first thing you will notice is the new UX. We've invested in usability and graphic design to make the kit nicer and simpler to use.

HL7Kit desktop applications shortcuts and the control panel

Another improvement is that now the installation and evaluation is much simpler because after installation (which is just a series of next-next-nexts) everything works with an internal SQLite database and by everything I mean everything! DICOM Storage, Q/R, Modality Worklist MPPS, and HL7 Orders ORM^O01 and Schedules SIU^S12 that are automatically mapped to Modality Worklist entries. Apart for the fact that it makes evaluation a snap, it also makes it really attractive for

Saturday, June 25, 2016


Back in the old days, C++ templates were the highest level of code abstraction for me. I loved creating template classes. On the other hand, Reflection, when I first learned about it, it didn't raise such an emotional feeling in me. It seamed like a complicated way to do simple things. About a year ago I was lucky to work with John Volkar from Bayer Healthcare. His project used Reflection to transform between C# data members and DICOM data elements. Recently, while working on another project, this technique came in handy. It's a nice example of how to use the Attribute class to link between a data member and a DICOM tag. Here it is. Thanks John.

First, how to you use it. It's very simple. Use the Tag attribute above the class member like this:

public string patient_name;

This just mapped the patient_name member to a DICOM Patient Name data element by using the tag (0010,0010).

Sunday, January 24, 2016

A ready-made DICOM Software that fits your needs - MODALIZER!

Its here, its ready, its published, MODALIZER, Take it for a ride! This DICOM Application is really a game changer! We took our DICOM Toolkit, combined it with our examples, mixed in our stand alone software and created the MODALIZER. Its an amazing software waiting for your imaging device to turn it into something big.

Lets say you're developing a new imaging technology and now you want to integrate it into the PACS environment. Take MODALIZER, configure your image capture application as the EXAP and that's it! MODALIZER takes care of all the rest.

Look at this DIAGRAM:
MODALIZER is a stand-alone DICOM application that implements an Imaging Modality according to the IHE Scheduled Workflow (SWF) Technical Framework. MODALIZER provides all the UI and the DICOM integration. The imaging part is performed by your technology that MODALIZER launches to the front after collection the patient and study details. Your image capture program acquire the images and then gives back the control to MODALIZER to complete the study. So simple. 
And it comes with DICOM Conformance Statement and even more you can license its source code! Check it our on our web site.

Tuesday, January 5, 2016

DICOM Conformance Statement

During the process of writing the DICOM Conformance Statement of DICOMIZER 5.0 I realized its been on my task list for more than two years! Its a complicated documented to write but two years ... that's a personal record.

So, what's the thing with this document, the DICOM Conformance Statement (aka DCS). Is it important? Is it mandatory to have one for your DICOM application? Why, When and How to read it? When to write one?

This is from the DICOM Standard:

"By comparing the Conformance Statements from two different implementations, a knowledgeable user should be able to determine whether and to what extent communications might be supported between the two implementations."
And of course the key here is "a knowledgeable user" ha ha!

DICOM Conformance Statement is a very technical document that describes (and some would even go further and say specifies) the DICOM capabilities of a product, a system, software or medical device.

There are two reasons to open the DCS:
1. To evaluate a product, before a purchase for example and,
2. When something goes wrong (maybe because you skipped #1 above).

There's a reason for this chapter position, very deep into the DICOM Tutorial. In order to be able to use the information in the DICOM Conformance Statement one has to have substantial experience and profound understanding of the DICOM standard and its fine details.

Lets take an example. You have a system that produces PDF reports and you want to attach them to the imaging studies in your PACS so when opening the study from the PACS workstation the images and the reports can be reviewed together. That's a nobel goal indeed.

Saturday, February 14, 2015

DICOM's role in the internet world and new release of RZDCX

There's an event held in Israel every year in Hadasa Ein-Karem hospital called IsraPACS. Diego Gicovate is doing a great job organizing it. This year I was invited to say couple of words and decided to ask the question "Where DICOM is going?" What it's role today with all the Internet and cloud technology.

Old lady knitting next to a Renault 4 car
Source: Unknown
(Please contact if you know this picture and or where it came from)

Usually, when I give presentations on DICOM, the introduction, the couple of slides in the beginning,  goes like this: "DICOM is very old, It's very big, It's a bit complicated, but hey, its working!" I have this slide (above) of an old lady sitting outside on a chair and knitting with a Renault 4 in the background. Then I review the parts of the standard, noting that, printed, it probably weighs something like 10 Kilo's and joking that I've read almost all of its 3 - 4 thousand pages. At the end  I show a slide with the poster of Monty Piton's film "The meaning of life" and replace it with the meaning of DICOM and then a slide saying, but hey, 1 standard, 1,000's of vendors 1,000,000's of patients, 1,000,000,000's of images, it can't be so bad, look, its working!

Monday, December 1, 2014

Lovely whether on the first day of RSNA 2014

It's that time of the year. I'm in Chicago again. Luckily, this year the whether is welcoming. We had a lovely two days and only this afternoon the temperatures are starting to drop. Tomorrow it's going to be below zero and hopefully it will get better during the rest of the week.
RSNA is a great opportunity to meet with colleagues and customers and see what's new and where things are going to. Apart from Big Data which is the number one interest right now, The two hot topics this year seems to be Image Sharing and Dose Recording and Monitoring (which I hope to cover on a future post). On the imaging side, I think the focal point is on Ultrasound technology that brings to the table its best up-side, no radiation damages! So Ultrasound has to evolve to the point where more and more anatomies and pathologies can be imaged with this great device. And it defiantly going that way. We're seeing giant steps in breast ultrasound imaging and many other fields will follow as hardware and software will evolve and mature. There's also the question of price and how it affects this technology. Ultrasound device is by 10's, 100's and 1000's less expensive to purchase and to operate compared with CT and MRI.

Image Sharing. Of course it links directly with big data which will also wait for a future post. As an ex-enterpuneer in this field with XRFiles, I'm always curious to see how the business model is built. One of the issues we had with XRFiles, apart from the misfortunate fact that we failed to raise money on it for various miserable reasons, was that patients don't want to see their images or any other medical data unless they really have to.

Saturday, September 27, 2014

Video to DICOM (and back)

This is a story of a lost battle. For many years I refused to add MPEG to DICOM functionality in my DICOM SDK. The explanation I gave to myself and to my customers was that storing video in PACS is a bad idea because video streams are usually very big and nobody ever watches them. From an engineering point of view, the size of the video is not so much a matter of disk space but rather a network headache. The way that the DICOM network protocol works, with all the different levels of timeouts and with no failover mechanisms for PDU’s may cause such huge objects to fail over and over when stored and restored. For the clinical point of view, I consulted with Radiologists friends from whom I learned that the driving force behind keeping most of this stuff is not clinical but rather medico legal. These excuses held for some time but eventually, because I’m an engineer but also a businessman, I changed my mind. After all, the customer is always right, and when more and more customers asked to convert video to DICOM, I realized that winning this battle means loosing customers and that’s not something a businessman should do.

Videos were added to DICOM through the mechanism of Transfer Syntax. All together there are currently four (4) video transfer syntaxes for different types of MPEG’s. Here's the list of these transfer syntaxes:
  • MPEG2 Main Profile @ Main Level : "1.2.840.10008."
  • MPEG2 Main Profile @ High Level : "1.2.840.10008."
  • MPEG-4 AVC/H.264 High Profile / Level 4.1 : "1.2.840.10008."
  • MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 : "1.2.840.10008."

If I have to guess, there will probably be more added in the future as new formats of video gain take over. The embedded document option that was taken for PDF would probably be my choice but I admit that I didn’t investigate the reasons that led to the way the standard went and there may have