What is this interoperability all about? Well, the time when the records are held in one place is quickly becoming the past. HL7 and other standards mostly addressed the issue of turning paper health records into digital. This requirement is still present, but nowadays there is a growing need to share those resources with other systems.
As an example let's take a scale which measures patient's weight and sends this information to the healthcare database. This is not a hard task even with HL7, but FHIR makes it even easier. The scale takes the measurements, wraps it into a special kind of object and sends it to the server. Naturally not all scales have Wi-Fi built-in, but they can communicate via Bluetooth e.g. Philips' eCareCompanion which sends it to the server.
In order to make sense of the interoperability, a common "ground" needs to be defined for the software to talk to each other. The key factor that distinguishes FHIR from its predecessors is the focus which has been put on the people who implement it. This means that it has built in support for common scenarios and attempts to be as cross-industry as possible.
The CDA taught HL7 that it won't matter if the machine doesn't understand what is being exchanged as long as it can be rendered properly for doctors to see. Hence, FHIR also implements human readability as base level of interoperability.
Because FHIR was written with developers in mind in has multiple reference implementations and publicly available test servers. The Starter APIs can be downloaded in multiple languages including: Delphi, C# and Java. Connectathons, health industry conferences, happen quite often to verify specification approaches and fix elements which are not working well.
FHIR is based on the concept of 80%/20%: "We only include data elements if we are confident that 80% of implementations maintaining that resources will make use of the element". If you need something which doesn't exists you can push it to extensions.