Protecting Your Investment: The Importance of ‘Software Design Patterns’ in Enterprise Imaging Application Development
 
Authors:
Rasu B. Shrestha, MD, MBA, University of Pittsburg Medical Center; Brian Kolowitz, MBA; Nathan Lauffer
 
Background:
Imaging applications, such as PACS, started to become prevalent in the early 90’s. DICOM and HL7 standards allowed for limited interoperability at the data level, but application interoperability did not exist.

Today, the power and versatility of PACS systems has attracted the “Other-Ologies” to the platform, but the tools provided do not always meet the users’ needs. Vendors are rapidly releasing new applications to solve these needs, but there remain major gaps.
 
Evaluation:
It is impossible to predict where standards and API’s will go in the future, but it is very much possible to predict the areas that will change. This paper attempts to identify the areas of change and encapsulate the change in easily workable configurable modules where software design patterns excel - such that this forms a solid foundation for consistent and effective application development, especially in the realm of enterprise imaging where a myriad of imaging applications are being born, and many more yet need to be created (Figure 1).
 
Figure 1

Figure 1
 

Software Design Patterns give common terminology and solution to creational, structural, and behavioral aspects of application development. They allow the application development team to communicate using common terminology and provide template solutions to problems. Software design patterns also abstract away change, separating the core business needs and the supporting infrastructure. Developing applications using Software design Patterns allows applications to support changing PACS vendors or clinical viewers with minimal impact. Our experience will be discussed in this paper. A custom application can be PACS agnostic and launch a variety of Radiology, Cardiology, or 3D applications seamlessly.

From an architectural and development standpoint, the Enterprise Application Framework is essentially meant to shield developers from having to make decisions that are not directly related to business logic. This allows them to concentrate on the more challenging (and ultimately more interesting) problems. It also means solving a problem once, and only once, and then encapsulating that solution in code. Both the .NET and Java world do this in similar ways. We simply plan on extending those to specifically apply to the overarching problems that we want to solve and how we want to solve them.
 
Discussion:
  • What aspects of today’s applications are most likely to change?
  • What aspects are most likely to remain constant?
  • What Software Design Patterns can be applied to these applications?
  • How will these Software Design Patterns insulate the application from the change?
  • What will be the benefit of the implemented Software Design Patterns now and in the future?
  • What technologies will facilitate the implementation of Software Design Patterns?
Conclusion:
Change is inevitable, and the only way to minimize the impact is to prepare for it. Although Software Design Patterns are not a silver bullet solution, they give the application developer the tools necessary to build more flexible applications that work with change, not resist it. This has been a proven methodology as we have developed over 40 different imaging applications following facets of the Software Design Patterns. We aim to clearly outline these ideas in this paper and show the direct correlation to successful enterprise imaging application development.

The idea is simple: “Make it so I can create a component that does a specific thing without having to worry about what the components it calls and what components call it. Then, let the infrastructure take care of how everything interacts with everything else.”

This accomplishes a lot of things. First of all, the developer only needs to focus on solving specific business problems, without having to worry about how those solutions will be integrated into the system. This is important, because it leads to loose-coupling between components. If components don’t need to know who they are interacting with, they can be used in more places with less side effects. This also leaves this interaction to be defined elsewhere, usually in some sort of configuration like that described above.