HL7 - Why Make It Simple If It Can Be Complicated?

I don't know anything about HL7 or HL7-XML, but this sounds like letting loose people that dont know zilch about the implementation side of things. In this case HL7 is translated into UML because the people involved know UML, not XML. Then the UML is translated into XML by the push of a button, generating monstrous XML.<p>Rant: dont let your tools substitute for personal knowledge of the domain.

HL7... what a nightmare! I remember having to work with it, and it was a convoluted solution where every provider and vendor had a different interpretation.<p>As bad as 2.3.1 is, it's still worlds better than 3. The best thing that can happen is for 3 to be scrapped. The worst part is its model. I worked with it for the purposes of PHIN-LDM, and I've never seen a worse clusterfuck. It made dailywtf look positively logical.

As if HL7 wasn't complicated enough.<p>I've written my own HL7 (pre-XML v2.x) message parser and generator in Java for work. I'd really like to not have to touch that code again, if possible. My code is easy enough to understand, but I don't want to have to rewrite it support this non-standard XML.<p>Just putting XML on the name of something doesn't instantly make it all easier.

Inefficiencies in health care standards are common, unfortunately. Look at DICOM, for example. Nearly every PACS on the planet uses their own method of abstracting data and transferring/storing medical imaging.<p>HL7-XML is already leaps and bounds ahead of the current spec, even with its obvious inadequacies.

My mind is screaming: "Just Fix It!".