It is not just VISUS that is celebrating a major birthday this year, but also two of the most faithful companions on this company's journey: DICOM and IHE. DICOM now has 25 years under its belt, while IHE is marking up 20. That's a good reason for taking a look at the early days and the success factors of both these institutions. Someone who has been involved with both standards since their inception is Dr. Jörg Riesmeier, today a freelance consultant and software developer. Quite incidentally, he is also closely connected with VISUS and not wholly uninvolved with the forerunner of JiveX.
Mr Riesmeier, let's open with the question of what links you to VISUS?
I have worked for many years at OFFIS, a research institute for applied IT, which came out of Oldenburg University. Even before the DICOM standard was published in its first version in 1993, OFFIS was involved in a prototypical implementation commissioned by NEMA, the standard's publisher. The software developed for that was further developed into a DICOM toolkit, which is DCMTK today. Particularly in those early days, the industry backing the standard was greatly interested in examining DICOM for its practicality and to present the results to the specialist public. Thus, over the years, there were many further tenders for developing prototypical implementations on very different subjects. One of these was consistent image display, connected with the so-called softcopy presentation states. In concrete terms, the challenge was that radiology images needed to be capable of being comparably displayed on various monitors and printers; and also that the settings the radiologist had selected for the image as part of the evaluation - grayscale windowing, graphic an text annotations, etc. - was not lost as soon as the data was called up at another workstation. At OFFIS, while we were very familiar with DICOM and visualization of medical images, however, not familiar with the development of GUIs.
This is where Klaus Kleber and Jörg Holstein came into play; at that time, they were working on a Java-based user interface for medical applications, at the Institute for Microtherapy under Prof. Dietrich Grönemeyer in Bochum. So we applied for the project together and won the tender. The software, which we presented for the first time in 1999 at the ECR in Vienna and subsequently at the RSNA in Chicago, was called DICOMscope - and, looking back, you can certainly say it was a forerunner of the today's JiveX.
So you are a true DICOm pioneer and contributed to ensuring that the standard was adopted in practice. And here it is, 25 years on. What has happened over that time?
A few things! The DICOM rulebook was initially 750 pages long, and today it is over 6,000. It's clear that you can't simply sit yourself down and read your way into the subject. However, if you were involved from the start and have kept on the ball, you can probably describe yourself with a good conscience as an expert. The numerous innovation that have filled these pages over time are widely varied in nature. One major expansion came at the end of the 1990s, in image consistency using the aforementioned presentation states. But over the past 15 to 20 years, the area of application of the standard has enlarged massively. Initially, it was only looking at cross-manufacturer exchange of radiological images. Later, the areas of cardiology,
radiotherapy, ophthalmology, surgery etc, were added. In parallel with this, data structures were also defined for signal data and medical findings reports. For many years, there has also been a trend for more and more parts of the entire workflow in healthcare facilities to be mapped and automated - and not just within the walls of that facility, but also beyond them. And it is precisely at that point that the IHE specifications come into play, because DICOM comes up against certain barriers in cross-facility exchange of medical documents.
What is the secret of DICOM's success? The standard remains uncontested today, and there is no immediate prospect of any alternative concepts.
To understand that, you need to take a step back and look at DICOM's predecessor, the ACR-NEMA standard. This approach originated in the 1980s, when the desire arose to be able to transfer images from large equipment - i.e. CT and MRT - to another device in order to view them there. Even then, users had one eye on not making themselves dependent on the manufacturers of this equipment. However, this standard was too imprecise in some aspects and allowed too much design freedom in implementation, with the result that "dialects" formed amongst the manufacturers that were not understood by all. And the manufacturers had an interest in standardization too, as ultimately their equipment remained in use for very long times and were producing data that sometimes needed to be archived and thus kept readable for up to 30 years. This was the background to developing the DICOM standard, which while it adapted some fundamental concepts from ACR-NEMA also learned from its mistakes. This development was driven both by users and by the industry.
From today's perspective, the concepts behind DICOM may perhaps appear somewhat old-fashioned and you can see from parts of it that its heart originates in the 1980s/1990s. But they still function outstandingly well. From the industry's perspective, there is absolutely no reason to change anything about it. After all, they have put decades of development work into DICOM and its implementation.
But in IT there has long been the opposite concept of proprietary solutions, which was also highly successful.
Big companies, in particular, liked it best when they could sell everything as a 'one-stop' operation - and they probably still want to do so today. In actual fact, until a few years ago the big manufacturers were still able to set their own standards in some circumstances, due to their size. But that doesn't work any longer, for two reasons. Firstly, these market-dominant companies which no-one can get by without no longer exist. And secondly, customers no longer commit themselves to such approaches, because cost and profit pressures drive them to use the best solution in all cases. And that only happens if a system is based on established standards.
With the IHE profiles the situation is somewhat different - they are not used in such an obligatory way as the DICOM standard. Why is that?
There are actually many different IHE domains, and the respective profiles definitely enjoy varying degrees of success. But let's look at the XDS profiles for cross-facility document exchange. The facilities have regulated this process for years themselves within associations or networks - whether via data carrier, VPN connections or via e-mail. The interest in changing the existing infrastructure - in other words, to fully re-devise a well-established process - is not always great. So there need to be clear advantages associated with switching to an IHE-based process.
A further aspect is that paper is patient, and sometimes you can wait in vain for something that is written down to come to life in practice. With IHE, 'sleepers' like this are not as rare as, say, with DICOM. And perhaps that is also because the application scenarios are not always taken from practice, but are sometimes developed via the lens of academia or in a theoretical brainstorming. With IHE XDS, that is certainly not the case. That is also shown in its use at national level in our neighboring countries of Austria and Switzerland, who use IHE as an obligatory requirement for digital files or dossiers.
So what is the recipe for success for a good standard?
The standard needs to be freely accessible. Both the DICOM specification and HL7 were fee-based at the start. That changed - and for DICOM, actually a lot earlier than for HL7. That way small, innovative companies also had the chance to use these standards without charge. In many cases, they also do not have to start from zero, but are able to use one of the similarly free toolkits available. Alongside this, the user needs to identify a genuine benefit, an improvement that ties in with a standard, since such interfaces not uncommonly involve a supplement. And ultimately, it needs backing from the industry. You shouldn't forget that companies need to commit employees who have plenty of feel for the issues and who can further develop the technical specifications, from a business and a practical point of view.
Dr. Jörg Riesmeier is a standards expert from the get-go. Today, he is a freelancer working in training, consultancy and software development, specializing in DICOM and IHE.
Dr. Jörg Riesmeier
It's a fact that without standards such as DICOM and HL7, there wouldn't be companies like VISUS. That would be regrettable not just from the viewpoint of those companies - the market would also be lacking the necessary diversity and strength of innovation. Standards open the way for competition. This, in turn, is the driving spring for technical advancements. A monopolist doesn't need innovations - and therefore stagnates in a proprietary, monopolistic world of progress.
It is only through open, freely-available standards that systems from different manufacturers can interact with one another and thus, jointly, remodel whole workflows. Process innovation is the buzzword here. With it, the challenges in healthcare in the 21st century can also be mastered. The shortage of specialists, for example, demands new ways of designing workflows in the best possible way. Through using intelligent IT in particular, it is currently possible to still ensure sufficient patient contact time for treatment. But insights gained from science should also be implemented - the buzzword here is "personalized medicine". That calls for information from a very wide range of sources. For that to happen, the data needs to be available in a standardized format that can be computer-processed, so that it can be used meaningfully in, for instance, AI applications. For me, the answer is clear: Without open standards, healthcare would be poorer, lacking many necessary innovations. So my call is: Join in, use standards!
Dr. Marc Kämmerer
Head of Innovation Management, VISUS