DICOM - the horse and buggy of Healthcare Informatics
dklovison
http://www.linkedin.com/e/vgh/2606243/
Looking for interested collaborators!
Mathieu Malaterre
Quoting your link:
...
Yes, DICOM worked, but so did the horse and buggy at one time.
Technology has advanced, patient security is more demanding, and DICOM
is no longer a good fit for the future of healthcare.
...
Could you please give actual facts ? What actual part(s) of DICOM do
you think is/are not fit anymore today ?
Thanks
Bartosz Wiklak
wrote:
Oh, I was sure no one will argue with this post - I was wrong,
I don't know if an author of this topic is really interested in what
we're thinking about this action and this "Just Say NO to DICOM"
action isn't just a joke but I'll add my humble 2 cents because
Mathieu apparently thinks it is worth trying.
I'm not en expert so I'll try to support myself with citation from a
person wiser than me.
David Clunie's blog Posted by David Clunie Saturday, November 22, 2008
http://www.dclunie.com/blog/blog/2008/11/dicom-exposure-attribute-fiasco.html
"If we ever had the chance to start DICOM all over again and "do it
right", I am sure that despite our best intentions we would still
manage to screw it up in equally egregious ways. We sometimes joke
about doing a new standard called just "4", so-called because it would
be the successor to DICOM 3.0, would not necessarily be just about
images, and which would be an opportunity to skip the past the morass
that is HL7 version 3. I doubt that we would really do much better and
would no doubt encounter Fred Brooks' "second system syndrome".
Indeed, DICOM 3.0 being the successor to ACR-NEMA already suffers in
that respect, perhaps being accurately described as an "elephantine,
feature-laden monstrosity". From what little I know about HL7 v3, it
is not exempt either."
The whole article is very interesting, I suggest to read it.
1. Is DICOM 3.0 buggy?
In some ways it is - sometimes I think the whole parts of DICOM are
hacks to make the standard look like it was not invented only for
images (just the stupidest example: QR IMAGE LEVEL vs. tag INSTANCE
NUMBER ); some quantities are stored in tags ( aQuantityInMilimeters,
theSameQuantityInCentimetersNooneTheHellKnowsWhy ) but others in f.e.
Code Sequence Macro ( BTW, its great concept but who of you has a
generic code to convert between different units in order to make
computations ? ); another small example is Imager Pixel Spacing vs.
Pixels Spacing hell.
2. Is DICOM 3.0 error prone?
Yes, just take a look at number of hacks in dcmtk and gdcm (examples
needed) made in order to step over the vendor implementation errors.
3. Should DICOM 3.0 be a subject of complete reinvention, is it worse
or worse designed than other similar standards?
Give me example of standard, even not so extensive as DICOM, where
user cannot make mistakes. In the other hand, give me example of
another technical standard, that joined so many different vendors,
institutions and private collaborators in an open framework with such
a great success. Because DICOM is indeed a great success that put us
out of the dark ages of private and proprietary implementations. DICOM
contributed to significant cost decrease and inter-compatibility
increase.
Who is able to beat this? Who has money to replace existing and good-
working standard with a new not yet invented but promised to be
better?
I think the whole action is just a joke, nothing more.
Bartek
Mathieu Malaterre
> On 26 Gru, 15:06, Mathieu Malaterre <mathieu.malate...@gmail.com>
> wrote:
>
>
>
> > On Dec 23, 9:05 pm, dklovison <dklovi...@gmail.com> wrote:
>
> > > Just Say NO to DICOM
>
> > >http://www.linkedin.com/e/vgh/2606243/
>
> > > Looking for interested collaborators!
>
> > Quoting your link:
>
> > ...
> > Yes, DICOM worked, but so did the horse and buggy at one time.
> > Technology has advanced, patient security is more demanding, and DICOM
> > is no longer a good fit for the future of healthcare.
> > ...
>
> > Could you please give actual facts ? What actual part(s) of DICOM do
> > you think is/are not fit anymore today ?
>
> > Thanks
>
> Oh, I was sure no one will argue with this post - I was wrong,
> I don't know if an author of this topic is really interested in what
> we're thinking about this action and this "Just Say NO to DICOM"
> action isn't just a joke but I'll add my humble 2 cents because
> Mathieu apparently thinks it is worth trying.
Well, I know some aspects of DICOM can be hard to implement, but the
OP specifically mentionned: "patient security is more demanding".
Which was not a known problem to me. I first thought of the MD2/MD5
cryptographically weak algorithms (but PS 3.15 only mention DES/DES3/
AES128/AES192 & AES256), but I wanted the OP to comment specifically
which algorithm he was talking about.
2cts
-Mathieu
Robert Horn
wrote:
> Which was not a known problem to me. I first thought of the MD2/MD5
> cryptographically weak algorithms (but PS 3.15 only mention DES/DES3/
> AES128/AES192 & AES256), but I wanted the OP to comment specifically
> which algorithm he was talking about.
Perhaps he is referring to the almost never implemented association
negotiation of user identity. Way back in the horse and buggy days we
put the ability to include either simple username or SAML assertions
as part of association negotiation. I don't think anyone uses this in
the field. (I would be happy to be proved wrong.)
When you go through the chain of trust and operational implications,
much of the "crucial" user information provided by user identification
is not that important. The DICOM TLS is widely available and used to
ensure that both ends of the connection are strongly authenticated as
legitimate authorized machines for data exchange. The user
information is secondary. Even with user information, once the DICOM
object is sent, the sender is fully trusting the recipient system to
provide appropriate protections from unauthorized use. Other users
will have access to that machine in the future. The sender cannot
force it to delete the objects, so the sender must decide before
sending any objects that the recipient will provide appropriate
protections. This downgrades the "crucial" user information to
"interesting" user information. Then in practice, the user frequently
turns out to be the machine itself, thanks to pre-fetching and
automatic dispatching. These same statements apply to WS-* and other
methods for exchanging objects.
Or maybe he was referring to simple password encryption for media,
which was only recently added. Certificate based media encryption has
proven impractical due to lack of universal PKI deployment.
It would be nice to know the actual problem he means.