The IHE (Integrating the Healthcare Enterprise) initiative provides essential guidelines for the deployment of a digital health information management environment. IHE, while not inventing new standards, creates a system-level and component-level design, based on the products of the leading standards, HL7, DICOM, and more. As such, IHE can be viewed as the "Standard of Standards".
The most significant value of IHE is that vendors can work on specific components of the enterprise solution, playing one or more of the IHE actor roles. IHE defines, for each actor, its external interface to the other actors in the system. Yet, the integrator of an entire IHE solution may find this job extremely difficult. The larger the number of vendors involved in the solution, the tougher the job. The complexity of coordinating all the components to work as one coherent solution multiplies and may become intractable. IHE defines very well "what" should be done, but not "how."
IHE-Bus offers a practical solution for the "how" question, with many advantages. This solution is borrowed from the business integration sphere. IHE becomes a platform, and each actor can be "plugged" into it in a simple step. New actors are independent of other actors already in the system. Missing actors can be simulated (by a "stub") until replaced with the real product in the future. Moreover, the entire IHE network is managed as a single coherent system with powerful tools encapsulating the enormous amount of knowledge and expertise deemed necessary to uphold this job.
The sheer amount of digital data generated by the proliferation of filmless medical imaging, poses great scalability and manageability challenges to PACS systems. Manageability challenges are aggravated when weighing legislative requirements. An architecture for an enterprise level PACS should support the management of assorted medical objects (e.g., images and reports). Additionally, the architecture should allow services, including performance and reliability, to be tailored to classes of objects according to complex and possibly varying rules. The design should be flexible, allowing for on-demand cost-effective scaling, using a mix-and-match selection of hardware, operating systems, and storage devices. In light of the increased reliance on stored data, it should ensure 24x7 availability, even during system upgrade, and allow pluggable support for future formats. The Medical Object Management System (MOMS) presented in this paper, is an enterprise medical imaging solution architectured to meet the above demands. Flexible, configurable and scalable content and source based management of
objects enables administrators to define and modify policies that govern various aspects of the objects' life-cycles, using either configuration files or a Web-based GUI. The modular architecture of MOMS includes (possibly multiple) instances of interface (DICOM, HL7 and Tivoli Storage Manager), storage management and administration agents. Agent instances are hot-pluggable, allowing for zero-downtime upgrades, and can be deployed on a heterogeneous and distributed infrastructure. Leveraging the expertise gained in the development and deployment of the IDMR research PACS project, combined with recent technological advances and modern middleware, MOMS delivers a solution for the present and future requirements of medical objects management.
Proc. SPIE. 5371, Medical Imaging 2004: PACS and Imaging Informatics
KEYWORDS: Image compression, Data storage, Databases, Medical imaging, Legal, Telecommunications, Java, Standards development, Distributed interactive simulations, Picture Archiving and Communication System
Managing medical digital information objects, and in particular medical images is an enterprise-grade problem. Firstly, there is the sheer amount of digital data that is generated in the proliferation of digital (and film-free) medical imaging. Secondly, the managing software ought to enjoy high availability, recoverability and manageability that are found only in the most business-critical systems. Indeed, such requirements are borrowed from the business enterprise world. Moreover, the solution for the medical information management problem should too employ the same software tools, middlewares and architectures. It is safe to say that all first-line medical PACS products strive to provide a solution for all these challenging requirements. The DICOM standard has been a prime enabler of such solutions. DICOM created the interconnectivity, which made it possible for a PACS service to manage millions of exams consisting of trillions of images. With the more comprehensive IHE architecture, the enterprise is expanded into a multi-facility regional conglomerate, which presents extreme demands from the data management system. HIPPA legislations add considerable challenges per security, privacy and other legal issues, which aggravate the situation. In this paper, we firstly present what in our view should be the general requirements for a first-line medical PACS, taken from an enterprise medical imaging storage and management solution perspective. While these requirements can be met by homegrown implementations, we suggest looking at the existing technologies, which have emerged in the recent years to meet exactly these challenges in the business world. We present an evolutionary process, which led to the design and implementation of a medical object management subsystem. This is indeed an enterprise medical imaging solution that is built upon respective technological components. The system answers all these challenges simply by not reinventing wheels, but rather reusing the best “wheels” for the job. Relying on such middleware components allowed us to concentrate on added value for this specific problem domain.
Proc. SPIE. 4685, Medical Imaging 2002: PACS and Integrated Medical Information Systems: Design and Evaluation
KEYWORDS: Medicine, Data modeling, Medical research, Medical imaging, Data conversion, Radiology, Binary data, Standards development, Electronic health records, Picture Archiving and Communication System
Electronic Health Record (EHR) is a major component of the health informatics domain. An important part of the EHR is the medical images obtained over a patient's lifetime and stored in diverse PACS. The vision presented in this paper is that future medical information systems will convert data from various medical sources -- including diverse modalities, PACS, HIS, CIS, RIS, and proprietary systems -- to HL7 standard XML documents. Then, the various documents are indexed and compiled to EHRs, upon which complex queries can be posed. We describe the conversion of data retrieved from PACS systems through DICOM to HL7 standard XML documents. This enables the EHR system to answer queries such as 'Get all chest images of patients at the age of 20-30, that have blood type 'A' and are allergic to pine trees', which a single PACS cannot answer. The integration of data from multiple sources makes our approach capable of delivering such answers. It enables the correlation of medical, demographic, clinical, and even genetic information. In addition, by fully indexing all the tagged data in DICOM objects, it becomes possible to offer access to huge amounts of valuable data, which can be better exploited in the specific radiology domain.
Most medical images today are generated digitally before exposure on film. In hospitals that employ Picture Archiving and Communication Systems (PACS), the images are also stored and managed digitally. Indeed, film copies of images are still used at large, but the new generation of filmless hospitals tend to minimize the production of films unless deem necessary, or required by the patients or third parties. There are basically two main reasons for working with films in 'filmless' hospitals. One is that in fact, these are 'less film' hospitals due to the film-oriented environment where they operate. Environment which has not yet entered the PACS and DICOM era; Neither in operation, nor in intercommunication. The other reason is that films are needed for legal purposes as a sole indicator to the medical image evidence used during diagnosis. PACS offer numerous advantages, but a high entry cost which can be balanced with the savings in films production and handling. However, as long as films are mandatory, they do not help to lower the inhibitory cost of PACS, and the use of films prevails.
Proc. SPIE. 3980, Medical Imaging 2000: PACS Design and Evaluation: Engineering and Clinical Issues
KEYWORDS: Human-machine interfaces, Data modeling, Data storage, Computer programming, Medical imaging, Data archive systems, Java, Multimedia, Standards development, Picture Archiving and Communication System
PACS usually comes as an integrated solution consisting of an archive, a communications module, and viewers. The DICOM protocol is used for inter operability between the archive, modalities and other viewers. We claim that the inter- operability between the viewer and the archive should be optimized for price/performance in a way that cannot be fully exploited by the DICOM protocol. For instance, the archive may use high performance data-compression techniques that need not be part of the DICOM standard. In other cases when data is stored off-line (on tapes or MO) and has to be retrieved to online storage, DICOM does not provide a means to identify this state. In this paper we make a position statement seeking additional flexibility and more possibilities for inter- operability between viewers and archives than is available via DICOM alone. In fact, we are interested to define an API (Application Program Interface), using the Java language environment. This approach is based on accumulative experience in the Java community that shows the feasibility of this concept. We call this proposal JDAPI for Java DICOM API, since the DICOM data model is reflected within. Java is one of the most important modern programming languages for rapid application development. Java offers many advantages for this purpose, such as a very convenient development environment, and a very rich set of standard packages. Working under a Java Virtual Machine (JVM) turns Java into one of the most portable environments in existence today. The most important advantage of our proposal in defining a set of Java interfaces, is to allow an independent development of the viewer and of the archive. The viewer component is considered an application for the interface, which works on top of an implementation of the interface. The implementation is a provider of access methods to a particular (DICOM modeled) archive. Vendors who specialize in writing viewers, will not need to worry about incorporating DICOM protocols and a local (or memory) archive (SCU) into the viewer. Vendors who specialize in archives, will not need to worry about user interfaces. With this API each vendor will have the freedom to develop its part of the system and be sure it will work on any complimentary viewer.
Real-time teleconsultation in radiology enables physicians to perform same-time consultation between remote peers, based on medical images. Since digital medical images are commonly viewed on PACS workstations, it is possible to use one of several methods for remote sharing of the computer screen. For instance, software products such as Microsoft NetMeeting, or IBM SameTime, can be used. However, the amount of image data transmitted can be very high, since even minute changes in an image window/level requires re-transmitting the entire image again and again. This is too inefficient. Looking for better methods, when restricting the problem to the use of same hardware and software of the same vendor, it is easier to develop a solution that employs a proprietary specialized protocol to coordinate the visualization process. Such is a solution that we developed, and which demonstrated an excellent performance advantage by transmitting only the graphical events between the machines, rather than the image pixels. Our solution did not inter-operate with other viewers. It worked only on X11/Motif systems, and only between compatible versions of the same viewer application. Our purpose in this paper is to enable inter-operability between viewers of different platforms, and different vendors. We distinguish three parts: Session control, audiovisual (multimedia) data exchange, and medical image sharing. We intend to deal only with the third component, assuming the use of existing standards for the first two parts. After a session between two or more parties is established, and optional audiovisual data channels are set, the medical consultation is considered as the coordinated exchange of medical image contents. Some requirements for the contents exchange protocol: In the first stage, the parties negotiate the actual set of capabilities to be used during the consultation, using a formal description of these capabilities. The capabilities that one station lacks over the other (such as specific image processing algorithms) can be 'borrowed.' In the second stage, when interaction starts, it should assume that the graphical user interface of the stations might be different, as well as working procedures. During the consultation, data is exchanged based on DICOM for the data model of medical image folders, and the data format of image objects.
The Web browser is an excellent environment for the rapid development of an effective and inexpensive PACS viewer. In this paper we will share our experience in developing a browser-based viewer, from the inception and prototype stages to its current state of maturity. There are many operational advantages to a browser-based viewer, even when native viewers already exist in the system (with multiple and/or high resolution screens): (1) It can be used on existing personal workstations throughout the hospital. (2) It is easy to make the service available from physician's homes. (3) The viewer is extremely portable and platform independent. There is a wide variety of means available for implementing the browser- based viewer. Each file sent to the client by the server can perform some end-user or client/server interaction. These means range from HTML (for HyperText Markup Language) files, through Java Script, to Java applets. Some data types may also invoke plug-in code in the client, although this would reduce the portability of the viewer, it would provide the needed efficiency in critical places. On the server side the range of means is also very rich: (1) A set of files: html, Java Script, Java applets, etc. (2) Extensions of the server via cgi-bin programs, (3) Extensions of the server via servlets, (4) Any other helper application residing and working with the server to access the DICOM archive. The viewer architecture consists of two basic parts: The first part performs query and navigation through the DICOM archive image folders. The second part does the image access and display. While the first part deals with low data traffic, it involves many database transactions. The second part is simple as far as access transactions are concerned, but requires much more data traffic and display functions. Our web-based viewer has gone through three development stages characterized by the complexity of the means and tools employed on both client and server sides.