I had a mentor at a company that engineered highly complex missile systems for the US Air Force. He drummed into me the mantra "when there is trouble, it will almost always be at the interfaces." Although he was talking about hardware systems, he could just as easily have been talking about software systems. For interfaces to work well, they must be clearly and completely defined, and they must be tightly controlled.
The term "integrated" implies that all the components of the software application share a common data model and store the data in a common data base. In an integrated system each instance of an entity (for example, a Patient) is unique; there is no need to reconcile multiple instances of what is logically the same thing and there is no need to synchronize the data to make sure the multiple instances are all at the same state.
The term "interfaced" is less strict than "integrated". The components of the logical application may, or may not, share a common data model and they may, or may not, store the data in a common data base.
If they do share a common model, then there is a simple mapping of the data among the components and the interfaces are easily implemented. An example would be the interface that connects an iTunes library to an iPod.
If they do not share a common data model, then the mapping will be more complex and may even be incompatible. An example of incompatibility would be two data elements that refer to the same logical thing, but use different coding systems to describe the thing and there is no one-to-one mapping between the coding systems. Although an interface may possibly be constructed to join the components, the interface will require design compromises to work around the incompatibilities.
If different vendors supply the various components (e.g., a "best-of-breed" solution), there is a high degree of risk that the interfaces will fail at some point in the future as the vendors advance their software products asynchronously.
Whether or not the interfaced components share a common data model, there will always be the need to synchronize the data to reconcile differences and to make sure the data on both sides of the interface are in the same state.
Integrated systems are obviously attractive. The benefits on entering data once and using it many times, with never a need to synchronize and reconcile the data, are enormous. However, it often happens that the integrated solution does not fill the need, and an interfaced solution is necessary. In addition, integrated solutions can, over time, become enormously complex, making them difficult to support and advance with new functions and features.
An interfaced solution may be less onerous than it first appears. Although the data models may be incompatible at the application product level, it may very well be that the components that have to be joined together do share a common model. In fact, in order to keep the system solution tractable, a single vendor may architect the solution as interfaced modules. With the interfaces cleanly mapped and under tight control, the benefits of interfacing can readily outweigh the benefits of integration.