> HL7 is one of those data standards that's only widespread because it's barely even a standard -- you'd have to write a different parser for every product or c

> HL7 is one of those data standards that's only widespread because it's barely even a standard -- you'd have to write a different parser for every product or combination of products you integrated with. I beg to differ, my past six months have been in the trenches with HL7 and while it's not perfect it's nowhere near as bad as you are making it out to be. I work for a medical billing company, and a huge initiative we have had is to start getting demographics from hospitals we bill for in real-time instead of the daily batches we have historically dealt with, all through HL7. We spent a lot of time implementing this, we have a "standard" mapping for HL7 messages that extracts all the demographic details we need from the standard segments, along with the ability to write a per-feed override to handle edge-cases where a specific EMR does something odd. To date, the majority of the edge-cases we have had to write are finding insurance policy ID's in weird places at the end of IN1 segments. There's been a few others, but the amount of customization we've had to do on a per-site basis has been extremely minimal.