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.