It's not time ...

As I write this, I am preparing to head off to Chicago to see my good friend and colleague, Charles Parisot, and also do something I very rarely get to do, which is sit in a room with him for several hours while he listens to other people speak.  I'm second or third up on the roster to roast him, and we will have hours yet after I speak for others to say more about Charles, who he is, what he has done, and so on.  In fact, we have about as long as a normal post meeting conversation with Charles to say it all, which in fact will barely be enough.

Rather than talk to you about what Charles is though I will get to that, I want to start with a few things that he isn't.  First of all, he is not a planetary body.  Yes, Charles does have a gravity well (it's pretty deep), and he does have an orbit.  In fact, he mostly fits all of the modern characteristics defining a planet:

1. He orbits the sun,
2. He is not a satellite ... for anyone or anything,
3. He has cleared his own orbit by repeatedly brushing aside all obstacles, and finally
4. He does have sufficient mass to be mostly round.

He even fits the definition for the old Greek term, which essentially means wanderer, and he certainly is a wanderer.  But, he is not a planet.  The reason I know that Charles is not a planet is because he fails under one very conspicuous criteria, which is that he has an event horizon, and should you get too close, you will never escape it.  Any the only things known to date which have an event horizon are black holes, former suns or larger bodies which cannot, by definition, be planets.

He's also not Carmen San Diego.  Yes, you can find him wandering all over the world, but that's the point.  You CAN find him.  All you need do is listen closely and head towards the action, or at least the action as it relates to Healthcare IT.  When I used to be in more regular touch with Charles, often the first question I would need to ask, is where are you today, even if I spoke to him yesterday.  Twice, without even knowing beforehand, I simply asked hum which ministry call he was on this morning and twice he met my expectations, although in all fairness, it was only one of those days that he was testifying to Parliment somewhere.

Charles does not sleep, except perhaps on long-distance flights.  I know this because I've gotten e-mails from him at all times of day, and so have you.

Charles doesn't do any real work.  That's what his gravity well is for.  Should you happen to get sucked into it, you will do the work.  Charles will just sit back and do what he likes to do, which is talk, and argue.  Charles will talk for so long, you will agree to do just about anything for him just in order to get some peace.  But if he doesn't do any work, how does he get so much done?  See, that's just the point.  Charles doesn't create projects, he co-opts them, often several at a time.  Then he puts them into a big bucket, stirs them up, and watches as things magically arise from the bizarre concoction of ideas.  Charles doesn’t have a say-do ratio, in fact he completely destroys the concept of say-do ratio, because no matter how much he speaks, what comes out of it is clearly more than what went into it.  It’s more like the ratio of aleph null to aleph one.

Charles is neither a noun, or a verb, although he has been used in both senses.  You can pull a Charles, or Charles someone.  Charles is also not an unstoppable force, he can be moved, but his reaction to outside influences is quite confusing, more like a centrifuge or gyroscope.  When you try to push Charles in a particular direction, be very wary, because his response will often be at right angles to the direction of the applied force.  Be very wary when he agrees with you (especially completely), because that often means you are about to be the recipient of a perpendicular reaction that is completely unexpected.  This is what it means to have been Charles'd.

The last thing I will say about what Charles is not is that Charles is almost certainly not retired.  We here all know that he will be continuing to pop up in our lives, perhaps in even new and more interesting ways, now that he will soon be removed from the restraints placed upon him by his current employer.  I'm certain we will all continue to see him, because fortunately or not, we are all inside his event horizon.

OK, I lied.  That was not the last not.  Charles is also not a recipient of the Ad Hoc Harley award.  But as to what he is, and I did say I'd get to that, is certainly overdue for induction into 2018 class of the Lords and Ladies of the Ad Hoc Harley.

Charles Parisot

Semper et semper ascendens deinceps

(ever and ever riding forward)

Medical Imaging Exchange

As anyone in the imaging market knows, the medical imaging market is not dominated by any vendor even if it quite a bit less fragmented than the EHR market.  Look at these reports on PACS and modalities (e.g., X-Ray, CT, MRI, Ultrasound, et cetera).  It's fairly common for an organization to have one vendor's PACS solution, another's modality, and a diagnostic workstation from a third.

The reason that these different systems work together inside an institution is because they adhere to the DICOM standards.  But there is a little bit more to it.  It is also because someone has taken the time ensure that they are configured appropriately to work together.  Once you get outside the walls of the organization though, you need more attention to interoperability.  The number of systems you want to be able to work with is even broader.

Let's look at a common use case (the one that John Halamka wrote about earlier today):  Getting an imaging study done, and having it be used at a different organization or facility.  The most common mechanism for exchange of the study is to create a CD.  Every time a family member of mine has had a significant imaging study done, we ask for the data on a CD before we leave, and we know to do so as early on as we can to simplify our lives.  Every CD I have ever received has included a viewer on it.  Only one included both Mac and Windows viewers.  Others just included a Windows viewer.  Those viewers are not meant for diagnostic quality viewing.  They are really just simple programs that allow a provider without any other viewing technology to see what is on the CD.  Any provider that I've ever really needed to give a CD to has had better viewing technology than what was on the CD.

Importing a CD from a foreign institution is not 100% successful, because not everyone complies with the  standards.  David Clunie (considered by many to be the father of DICOM) talks about this in a paper he presented at RSNA in 2010.  Most of the CD import failures are attributable to NOT following the DICOM standard, or other relevant specifications. The Great Aussie CD Challenge (pdf) tested more than two dozen CDs in 2007 for standards conformance (an eternity in Internet years), and came to similar conclusions with regard to conformance.  I'd love to see a more recent repeat of this exercise, using newer technology because the situation has improved (PDI was first introduced as an IHE profile in 2005).

This study showed that nearly 80% of CDs can be imported successfully.  There are standards and profiles which could improve the success rate (and which were used in the CD challenge previously mentioned).  The IHE Portable Data for Imaging Profile was strongly recommended by this Johns Hopkins study, in Australia (as a result of the challenge), and by the AMA.

This report shows the number of organizations that support PDI in their products.  It is an amazing list, which includes all of the vendors previously named in the market share reports at the top of this post.
What it doesn't show and is even more important is how many provider organizations are actually using those capabilities. As Dr. Clunie's paper indicates, it is very likely that organizations aren't configuring their systems to USE the AVAILABLE standards and profiles.  One question that they need to address is what the value is for them to do so.  As John Moehrke points on in this post from last year, getting your "Damn Data" seems to require a mandate to do so interoperably.  This isn't an implementation issue with respect to standards, but rather a deployment one.  I've implemented PDI in 2008, and actually done so over top of the XDS-I specifications.  It was one of the simplest standards-based integrations I've ever done.  Getting someone to want to use it?  That's a different story.

Exchanging data on CD isn't ideal.  There are a number of issues beyond dealing with the data in a standard format that also have to be addressed, many of which Dave Clunie points out in his RSNA slides.  Others are addressed in this 2008 Radiographics article by Mendolson and others.  These include things like patient identification, translation of procedure codes used at different organizations, bandwidth and storage issues, et cetera.

Ideally, you'd think it would just be a matter of transmission of the study from the organization where the study was done to the organization where it is going to be reviewed.  Pragmatically, that doesn't work where we live because the value of that "network" isn't perceived by anyone other than the patient, unless the imaging center and the reviewer are somehow financially connected. Payers do see the value, and where I live, the possibility that a payer network would be established to support such an imaging exchange is certainly viable, but has yet to be realized.

Point-to-point exchange (e.g, via Direct) wouldn't really have worked in one case for one of my family members, because we didn't know who the specialist who was going to perform the surgery was until long after the image was taken (but reading the CD was really simple).  You need something like the network in Philadelphia and New Jersey, or in Canada described in the Radiographics article above.  These networks are built upon the IHE XDS for Imaging protocols.  Both IHE and NEMA are also working on the next generation of web-service enabled protocols to support more advance image sharing.

John Halamka proposes the use of The Direct protocol to exchange images.  The Direct project was designed to support clinical data which is several orders of magnitude smaller than imaging study data.  This article documents the size of some typical imaging studies (see Table 3).  These range from 15Mb to as much as 1Gb (for CT Angiography).   Moving forward into the world of advanced digital imaging for pathology, you could get into the terabyte range (that's more than a 1000 CDs, a hundred DVD's or a double handful of Blue-Ray disks).  Clinical data, such as that in a CCD takes from a few Kb to maybe a couple of Mb if someone has abused the standard to provide a full data dump.
 
Anyone who's had any experience sending multi-megabyte files over e-mail will probably realize the limited viability of Direct for anything other than simple studies (e.g., X-Ray or Ultrasound).  The reality is that providers using the "simplest of EHR systems" probably won't have the storage capacity available to deal with medium-to-large studies.

One of the rationals for the way DICOM is structured is that you don't need all the data all of the time. Studies are large, but what the provider often needs to view is much smaller.  The tie-in to transport in the DICOM standard was to address this issue, and transport only what is needed when it is needed for viewing.  That's a much more efficient use of network bandwidth, and still gives providers what they need, which is, according to the AMA, access to the complete diagnostic quality study data.

With regard to proprietary data, and viewers:  There is no need to physically separate proprietary data in the image stream, but there is a need to tag it so that a "vendor-neutral viewer" can process the data, and DICOM does that.  Every proprietary data item in a DICOM conforming object is clearly tagged as such, and if you read the Vendor's DICOM conformance statements, those tags are documented.  And if they conform to IHE's PDI profile, they will also have a DICOM conformance statement.  If the system conforms to the DICOM standard, you don't need to understand the proprietary data to view the image.  There are really good reasons why some systems use proprietary data, and store it within the DICOM study.  But that data should not impact a standards-conforming viewer.

We don't need a new standard to address most of what John complains about in his blog post.  What we need is for organizations to actually USE the standards which are already widely available, and to configure their systems to do so.  That would address a large part of the existing problem.  Canada has certainly shown with their deployment that XDS-I works for regional imaging exchange.  Regarding the companies that John mentioned on his blog, all three support XDS-I in their solutions.

The one case where a new standard is needed is in the interchange across distributed networks of DICOM study data.  That is work that DICOM has already started.  I should note that the DICOM standard applies to regulated medical devices. I will happily leave the development of the new DICOM standards to experts in diagnostic imaging.  I don't think throwing a lot of non-expert volunteers at the problem will make that work go any faster, or produce better outcomes.

   Keith