Universal EDI Envelopes? June 20, 2008
Posted by Bill Chessman (Inovis) in EDI, Technology.Tags: EDI, EDIFACT, HL7, New Orleans, Standards, X12
trackback
As I’ve mentioned before, I participate in the X12 standards development process and attend the trimester meetings. The most recent of these meetings was held the first week of June way down yonder in New Orleans. On the plus side, I love the food there. On the minus side, the food doesn’t like me quite as much as it used to—it misses my gall bladder (gone these last 10 years) almost as much as I do. But I’m getting beside myself.
Perhaps you’ve heard the rumors of a new envelope to replace the venerable ISA/IEA structure. I’m here to tell you those rumors, so far, are patently false. The ISA/IEA and its inner cousin, GS/GE are doing just fine, thanks and have a reasonably good long life ahead of them…unless that all changes.
The most interesting of the gatherings in New Orleans (not counting Bourbon Street, of course) was a special session to discuss the possibilities of a new X12 enveloping scheme. Specifically, the session was an open forum to gather business requirements to determine if new envelopes were needed and, if so, what they needed to do or be. There were probably fifty people in attendance (a little over 10% of the trimester attendees) and the response was unanimous: There should be new envelopes and they should be able to do everything. (Okay, not the hula-hula, but just about everything else.)
A few of the high-runner requirements included:
- Support any business payload (X12, HL7, XML, other).
- Support acknowledgments at interchange, functional group and other levels.
- Support security.
- Support multi-hop scenarios (particularly pertinent to Healthcare).
- Support character encoding schemes and localization.
- Support an escape character (similar to EDIFACT’s release character).
There are too many requirements to list here, yet the population providing those requirements was fairly small. So, I’m throwing this out to the world (or at least the blog-reading sector…Note to self: wonder what percentage that is???): Does X12 really need a new enveloping scheme and, if so, what do you think ought to be included in it?
Comments
Sorry comments are closed for this entry
Two schools of thought come into play here:
“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…?
Two comments:
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.
speaking as a user, and not a member of X12, the ISA/GS enveloping structure has served us well over the years, and continues to do so. I do not think email addresses are a good idea because they are always changing (new service provider, fed up of spam, etc.) I do not see anything wrong with the present method of enveloping (although there are many out there that do not understand it).
Whilst I know next to nothing about X12 (dor it is a US only format) I have implemented interfaces using all sorts of messaging-based standards.
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?
For those of us who have designed and implemented complex systems, the challenges of deciphering, tracking, moving and responding to messages are quite large. I hope the common/standard envelope initiative can begin the discussion of providing solutions to overcome these challenges.
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
very good points, Dan. But it begs the question – do we need to really build a new house…? Isn’t our current house doing the job…?
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….
I am glad Craig chose the house analogy.
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,
[...] this one, are also examples of social media. We are building a good community here. Just read this recent post and the comments some of the readers have posted. This is a great way for folks here at Inovis to [...]