The first issue is making sure everyone knows what HL7 is.
It is a way to replace [medical|billing|insurance] coders and save a [pharmacy|bank|insurance company] money.
That's the wrinkle on top of all the normal issues in software development.
- Scope Creep
- Incomplete specifications
- Invalid proprietary specifications that "Can't be changed"
So, you contact your [Pharmacy|Bank|Insurance Company] who wants to squeak out all the money they can from an HL7 interface to the facility who uses your software. Your contract is with the facility, their contract is with the pharmacy, the [Pharmacy|Bank|Insurance Company] has no clue how your software works, the facility has no clue what HL7 is and you're ticked off at the pharmacy because they constantly tell you that your software is buggy.
I believe the problem with HL7 is that it is mostly done on the cheap. HL7 3.0 may never materialize because it will never monetize.
If you're going to "pay for HL7" remember that you're paying for HL[1-6] as well. A SOAP interface is not HL7. An HL7 message parser is not HL7, neither is a message generator.