In the early eighties My wife and I purchased a house built in the early fifties. It was a perfectly adequate house for our budget and needs.

In the mid-90’s we decided to update the house. We spent a fair amount of money and time remodeling the house. Once we were done, we decided that the dining room needed to be bigger. This turned out to be less traumatic, but almost as expensive as the rest of the project.

The moral of this story is: it is very hard to predict the future. It is expensive to fix things after they have been built. It is best to try to get the job done correctly the first time, but that is often not possible.

I suspect that there are some readers of this blog who have a deep understanding of messaging/transaction processing/queuing and know what a perfect universal envelope might look like. X12 welcomes your input and participation in this endeavor. It would be nice to build one which works as well for the next 30 years as the current ones have for the last 30 years,

Sure, there are some drawbacks to the current enveloping standards…. and maybe they surely could use some work… But by standardizing, we may be opening ourselves up to a whole new batch of issues with which we’ll have to deal…

Look back at the whole “Y2K” broo-hah… the engineers in the 40s, 50s and 60s didn’t think that far in advance – that we’re going to need to change out the century of the years – or we’ll have duplication. Well, if we were to standardize some of the concepts in the envelopes – could we not end up with that same kind of issue?

In his comment above, Bill talks of using e-mail address and Keith counters the comment. Now let’s take your comment of standardization into the e-mail realm. Imagine we only had (user name)@e-mail.com for e-mail addresses. Think of how many John James Smiths there may be in the world… or even Dan Kazzars… And what kind of confusion might happen if you receive e-mail for another Dan Kazzar. Or John James Smith….

It is not that ISA/GS are broken or that the envelopes of any other SDO are broken. It is simply that:

A) Envelopes are tightly tied to syntax (HL7 folks cannot speak X12 and vice versa, eventhough they are almost the same syntax)
B.) Today’s envelopes do not carry enough information. This force companies to develop large systems to meet tracking needs.
C.) We are inhibiting the growth of our electronic connections by using disparate envelopes. I.e., we have separate networks for claims, supply chain, credit card and electronic prescriptions. By standardizing, we open up possibiities.

Sometimes we need to fix the foundation to build a new house

The fact that the world has largely moved on from the messaging paradigm ot a services paradigm can’t go unnoticed by standards bodies such as HL7 or X12. HL7 is as of yet unsure how to intertwine both paradigms – and how to create one single envelope for both of them.

None of the requirements listed in the blogpost are in any way specific to X12, HL7 or such standards – they are generic in nature. The question therefor has to be raised: isn’t there some applicable standard already out there that could serve the role of the new X12 envelope?

1. The notion of enhancing/redefining/replacing the transmission envelopes has been a topic of discussion within X12 for some time and has not been taken lightly. The primary motivation, I think, is keeping X12 standards relevant and up to date with modern technology. As a very basic example, some have suggested that e-mail addresses might make good sender and receiver identifiers. The respective elements in the ISA segment (limited to 14 characters each) are too short to fit any but the shortest of e-mail addresses. Would any of the changes make X12 easier? I don’t think that’s the point.

2. I would also point out that the suggestions here were not simply plucked out of the air and not by a small committee who suggests changes just to justify their existence. The suggestions I noted in my original post were gleaned from X12 members who represent a broad range of industries (and by the way, the list I presented, was a sampling of the suggestions). Having said that, there is a larger group that uses X12 standards but does not participate or hold membership in X12. My question was an attempt to survey that larger user base.

“If it ain’t broke, don’t fix”

and

“That which does not change gets left behind”….

When it comes to the first thought – not broken, no need to fix – these theories work pretty well for many people, industries and “things” and yet it also means we don’t get new advances and technologies and ways of thinking… We’d all still be living in caves with rocks and clubs and hunt things down and wear leapord print loin-cloths… not always a pretty sight…

We wouldn’t have cell phones (a current pet peeve of Mines!) or computers or EDI or diet Dr. Pepper or microwave popcorn or vaccines for polio or various pox diseases and other afflictions of humanity.

But then again, we wouldn’t have lived through the Cold War and the threat of Nuclear Winters…..

This leads into the latter ways of thinking – adapt or die…. Change is an irresistable force to very much be reckoned with. Without change, without thinking of new ways to do things – we’d not have fire… or the wheel… or trans-Atlantic and Carribbean cruises and Disneyland…. We would all die by our late 30s or mid 40s… Some of our greatest leaders never would have survived childhood….

Truth be told, change IS needed – whether to find a cure for a disease or consolidate business practices for better acceptance and usability across the lives of the masses.

But, then again, change just soley for the sake of change is not the right answer either. Just to change something because “change is good” isn’t right. You risk … offending … those that use the product and are quite happy with the way things are and the features and the usability of the product. Just changing it is not good….

X-12 needs to be sure that they’re making a good and a valid change that will make EDI easier … well, less complicated, anyway … for all to use and not just making a change to change things….

Does this anwswer the question…?