|
Martin,
I
think my comments were misconstrued in some way as endorsing X12 to the
exclusion of XML. That's not what I'm saying. In fact, your
refutation of my remark ignores the end of the statement. Rachel Foerster
said it better than me: "The real key to
successful automated electronic business messaging is a STANDARD
SEMANTIC." This is what I was driving at when I said "...unless the
presentation and arrangement of the data in XML is much better." I agree
with your comment "In the development cycle, the costs savings of an
intelligible syntax multiply." I must re-iterate, "In the development
cycle..."
What
I've noticed (and this is fairly well born out in the two sample X12 to XML
transliterations) is a distinct quick, almost knee-jerk fast, leap to XML
without the vital development cycle. In the example from Joe Barton, the
entire syntax structure (including separators) was retained within the
XML. You have to walk through the XML tags like an extra set of separators
that added nothing but dead weight. Anyone in the quick-let's-implement
mode who happened to pick that one would be sadly mistaken in any belief of
advantages of the new technology...not to say XML is bad, just that particular
example. In the case of the sample Kevin Day sent along, the separator
characters in the X12 are simply replaced with "smarter" separators that give a
better idea of where the data comes from however the data element relationships
and values remain the same. Better than the other example, but is it
sufficiently compelling to replace existing EDI technology. (This, by the
way, is not in any way meant to vilify, offend or cast aspersions upon Joe or
Kevin...I understand that they were sending the samples as samples and not
endorsements...I worry about panicky people, under the gun, who pick these
things up and run with them without doing their due
diligence.)
So, my
point is, if we're going to use XML, let's do it right so we don't have to do it
over again when the next big thing happens. I'm totally in favor of a
Standard Semantic as Rachel says. Human readable would be nice,
too (assuming we're willing to concede which humans will be reading
it). XML can be used in so many different ways that every user can have
his own version and his own semantics and his own data rules...and therefore
every one who trades will need to have a unique implementation for each
partner...unless the can land on a Standard Semantic.
Best
regards,
Bill
Chessman
Inovis(tm), Inc.
I love
seeing this slugfest between agreeable opponents!
Now, I'd
like to take a step back from the arcanery and look at it from a business
analysis/project management/implementation perspective.
We've
just gone through (in fact, are continuing to go through, which is kind of the
point) an EDI translator evaluation/procurement/training/implementation
effort. The fact is that while XML may be human-readable, X12
is absolutely NOT human readable. This is not a minor issue -- it goes
to the heart of the current development problem and affects costs in a very
non-trivial way.
Kevin
points out (and illustrates) that: I don't believe anyone can deny that with
almost no experience in the XML syntax you could read that document and
understand what it contained.
A good
part of our costs in this effort have been associated with getting our mappers
trained to understand, read, and finally THINK in X12. A well-defined
XML standard would have shaved four months off of this process, and let my
people get to work on the true "problem space" rather than creating a new
problem space of interpreting everything they new about healthcare into
X12-ese.
I submit
this to directly refute what Bill said:
When
you get to a document as complex as, say, the ever popular 837i, the use
of XML vs X12 syntax is not going to simplify the data when
it comes to mapping...unless the presentation and arrangement of the data in
the XML is much better.
Given
the capabilities of XML, and the incapabilities of X12, how could it
be any worse?
If it's just a 1-to-1 transliteration from
X12 to XML, there is no benefit gained for mapping and translation...you've
just introduced a secondary translation step...and I doubt there'd be much
cost savings in that.
In the
development cycle, the costs savings of an intelligible syntax
multiply.
Yesterday, in a project tech meeting, I asked one of
our mappers to explain the problem she was having with secondary insurance
data. She threw her hands up in frustration and exclaimed, "It's just
not going into loop 2320!" This represented two bellwethers -- she was
thinking and speaking X12, and she had just moved beyond the ability to
communicate her problems to the rest of the analysis team. Great
victory, huh? And it gets far worse when you go from the arena of the
technical team into the realm of the hands-on subject matter
experts.
Kevin
pointed out some excellent "human intervention" advantages of XML. The
ability of the entire development team to speak the same language is not a
"sexy and convenient" frill -- it goes directly to development costs,
reduction of miscommunication, rework and design quality.
The
problem is that many of the people who are most influential in this process
are still working under the old rules we learned when we did our Fortran and
Cobol programming class projects on punchcards:
Storage
is costly -- eliminate redundancy
Bandwidth is narrow -- constrict your
datastreams
Programs
are stupid -- microdefine your data
Ambiguity does not compute -- accept no
variation
In an
age of $500 workstations, broadband-to-Dogpatch, blobs and fuzzy logic, why do
any of these precepts continue to hold weight? To put it more
succinctly, does the fact that an "X12
feed represented in XML [can be] 10-20x the size in bytes compared to the
original document" mean anything when employees are sending megapixel
pictures of their kitties via interoffice email?
Martin
Jensen
Project
Manager
St. John
Health System
-----Original Message-----
From: Bill
Chessman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June
04, 2003 18:38
To: WEDI SNIP Transactions Workgroup
List
Subject: RE: [BULK] - RE: [BULK] - XML vs. EDI
Kevin,
On
the whole I think we're thinking in the same direction. My intent was
to offer the opinion that XML is not the panacea that many still hold it to
be (nor do I nor did I mean to imply you suggested such). You're point
that XML and EDI should co-exist couldn't be more correct. Frankly, I
think of them as more similar than different. The same data is
transmitted, it's just different windowdressing. My concern was that
folks who are desperate to support XML but don't have time to learn it might
grab onto a particular example and assume "This is how all XML is done!"
without understanding the unavoidable nuances and issues of
implementation.
From a standpoint of simple XML-based forms via
Word, etc. I can easily see your point. Sounds like a poor man's DDE
system. I also appreciate that human intervention is necessary at
various point through the data trail. Ultimately the data has to get
to somebody's database (one presumes at least one computer database as
opposed to 3x5 cards or paper folders...) and XML in and of itself does not
provide anything more than EDI does in this department. Someone must
still provide mapping and translation to get from transmitted data to stored
data and vice-versa. When you get to a document as complex as, say,
the ever popular 837i, the use of XML vs X12 syntax is
not going to simplify the data when it comes to
mapping...unless the presentation and arrangement of the data in the XML is
much better. If it's just a 1-to-1 transliteration from X12 to
XML, there is no benefit gained for mapping and translation...you've just
introduced a secondary translation step...and I doubt there'd be much cost
savings in that. The problem is that everyone wants to get on the new
technology bandwagon without sufficient analysis. As you say, wisdom
and forethought need to go into such a migration.
(As a side-bar, the industry--indeed any industry
that relies on computers--might be better served if programmers spent more
time providing better ways to deal with--or, dare I say it?
prevent--exceptions than are currently the norm. This applies to code
cleanliness as well as better usability, but again, I digress.
*sigh*)
XML, in and of itself, does not guarantee human
readability. XML does guarantee some small amount of hierarchical
relationship between data items but even that is minimal. Again the
word "could" or "can" come into play. XML can provide human
reability (of course an XML document in Chinese, for example, may be
readable to certain humans but not to others--on the other hand, a tag such
as <TWera42Qmg> might not be meaningful except to a very specialized
few). XML can provide data "rationality" (for lack of a
better term). I like to think I'm an optimist and that all the
programmers out there who write software and design XML data structures are
rational and thoughtful and thorough and careful and never, never in a rush
to "get it done and damn the consequences"...they all are, aren't
they? 8-)
I
also take issue with the statement, XML is "self describing which X!@
[sic, I assume you meant X12] obviously is not." XML tags,
by themselves don't provide any semantics at all, so I'm not clear what you
mean. I guess if you have a tag such as <CustomerPhoneNumber>
that may be meaningful, but there's nothing that says what's contained
inside has to be a phone number. From an XML perspective
<CustomerPhoneNumber>fuzzy-wuzzy</CustomerPhoneNumber> is just
as valid as any other XML data (it's well-formed according to XML
syntax). If it's not in the DTD or schema then the whole thing is
wrong, however if the value is invalid, that's a business problem, not a
syntax problem. So, at the very least, an XML document must have a
corresponding DTD or schema to provide any validation at all. That is
to say, the XML parser can reject the data if the
tag <CustomerPhoneNumber> is not in the DTD/Schema or perhaps if
it occurs in the wrong place or the data is too long, but it can't
reject the data because it isn't really a phone number...that's an
application program's job. (I'm making the assumption here that an XML
handling system has two primary parts: a parser for the XML
and customized business logic to be applied after the XML has been
parsed.) Well, it turns out that X12 has something similar (although
admittedly not as sexy or convenient): it's called the standard
definitions within a given release. Each release of X12 (there are
similar things in other EDI standards) provides a definition of every single
element, segment, code and transaction set. In fact, electronic copies
are available against which X12 data can be validated in the same manner as
XML. Is it as easy? Probably not. Is it possible: I
know it is.
Finally, I definitely agree that, all things being
equal, there are more applications that can benefit from XML. Book
publishing, for example has the XML-based DocBook which provides a great way
to set up a book text in such a manner that applying a particular XSLT
style sheet will produce an RTF file or an HTML file (among other
formats). XML seems a more reasonable candidate for anything that
is web/browser based. I'm just not convinced yet that XML is
better at EDI (that is, unobstructed computer-to-computer data
transfer) than EDI is. Of course, this is the same discussion
that's been raging in the e-commerce, b2b arena for several years and I'm
sure my comments won't sway anyone any more than anyone else's will.
8-)
Okay, having rehashed two years (or so) of debate
on the subject, I guess I'd better stop before I drive anyone closer to the
brink. 8-)
Best regards,
Bill Chessman
Inovis(tm), Inc.
Bill,
My intent was not to address all the various issues raised on
the subject but to merely answer the original request which was a simple
explanation of what XML is and provide an objective opinion on how it
could be viewed in relationship to X12.
Now that the simplicity aspect of my response is out, here are a
few more details I sense you were looking to get out of it.
First, the dialect I chose in the example and you picked up on was
indeed one example that one "could" be used. The attributes that were
added were in fact optional. Generating them would in fact be an optional
choice one would use. The actual product used to generate that in fact
provides such an option. I could debate the advantages and disadvantages
of carrying over the original X12 feed but that would be a lengthy
conversation. I would agree that one aspect of the use of XML which has
been skirted a bit and you somewhat touch on is the size of documents
produced by XML. Even with the most simplistic forms there is an embedded
overhead associated with it. I've seen an X12 feed represented in XML
10-20x the size in bytes compared to the original document. With the added
human readability comes at cost. XML is certainly not the answer itself
but it does provide a much lower cost of entry for the smaller players or
providers as the case may be.
My concern on this stream of emails is that most of them view EDI,
X12 in particular, and XML as being mutually exclusive which is clearly
not the case and has been demonstrated by many payers and CHs I have
worked with the past few years. By including a simple syntax translation
(i.e. EDI2XML and XML2EDI) functionality while maintaining the semantics
across the translation the larger players are now able to provide more
cost effective means to communicate with their trading partners while
maintaining the interfaces to their backend systems. By converting X12 to
XML you are now able to render the HIPAA transactions in a variety of
forms be it HTML through a web page, another dialect of XML, or even to a
proprietary flat file format (yes, XSL is the main tool to perform this).
On a side note, one of the main reason for the creation of XML was
the ability of documents to be self describing which X!@ obvious is
not. Applying Stylesheet is a means to provide en even more
human readable form such as a pretty HTML page but should not be
required to be deployed in order for someone to be able to interpret
a document. The partial sample I shared is one extreme of XML. I don't
believe anyone can deny that with almost no experience in the XML syntax
you could read that document and understand what it contained. The meaning
of each field and the relationship of one field (element) to another
(e.g. it's parent). These techniques continue to be employed by
more and more "gorillas" to lower their cost with the automation (although
not entirely) of their adjudication processes and reduce their paper
feeds. If there were ever to come a day when the industry were to indeed
standardize on a particular XML dialect the opportunity to directly
connect even more providers to payers will become much more feasible.
Although we may tend to think that the focus may indeed be the need to
have the machines on two sides of a relationship communicate directly that
is only one aspects of it. Inevitably human intervention is needed. Not
only from the initial entry point into the process flow but at various
points along the process such as exception handling, real time reporting,
etc.. XML provides a much better form in which to give a business
user a view into the data as it passes through the processes. As I
state, passing the added meta-data along with the data itself does come at
a cost and there are various ways to limit that cost. However; the
benefits for the overall cost reduction in the industry in my opinion far
outweighs the cost.
The mentioning of the existing applications that are found on
everyone's desk which already support XML was to illustrate the the fact
that the tools are already present and fairly inexpensive to use for the
creation of XML. It doesn't take much time or effort to create a simple
Word form that can generate an XML document such as a claim which
could then be emailed with a response emailed back within hours. On the
payer side supporting XML gives the potential to provide more web
interfaces into their system. Yet, the issue of non standardized XML for
Healthcare becomes the stumbling block. No one wants to invest in
interfaces electronically with XML without a common standard since it will
require costly alterations later when one is finely produced which leads
us back to why X12 is the one electronic document protocol we have left to
use. It contains a common syntax and semantic dialect.
My bottom line point is that both EDI (X12 is merely one form) and
XML can and in all practical purposes should co-exist to both lower the
cost of entry by the smaller players (e.g. office mgt software vendors) as
well as allow the larger players (payers) to capitalize on interfaces to
existing backend systems that took years and millions to design, develop,
deploy and maintain. A drive to a common form of an XML standard
would be a key part of bringing those of us that produce and consume the
documents closer to allowing complete interoperability which in turn will
lead to a reduction in the processing steps thus reducing cost. In the
meantime, the need for such intermediaries to help with the communication
across the various entities in the process flow is inevitable as they
provide the needed function that thrives where standardization is limited
be it in the form of document or transportation protocols. This
doesn't mean XML can't be used now in healthcare processes. It's just need
to be used wisely with forethought into migration to a standard whenever
that becomes reality.
Kevin
Kevin Day - Sr.
Program Manager
Vitria Technology, Inc.
www.vitria.com
945 Stewart Rd.
Sunnyvale, CA 94086
TEL
: 408.212.2529
CELL : 408.368.7783
The opinions expressed in this email are solely of the author and
do not necessarily reflect those of Vitria Technology,
Inc.
-----Original
Message-----
From: Bill Chessman
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003
9:44 AM
To: WEDI SNIP Transactions Workgroup
List
Subject: [BULK] - RE: [BULK] - XML vs.
EDI
There are some interesting points here, but I'd
like to focus in on a couple that I think get overlooked in all the
hype. Kevin, in his excellent answer points out that he has, "...a
simple example of what a small X12 document could look like in one
example XML dialect..." My particular pinpoint focus is on the
word "could". The situation today is that there is yet no
"official standard" DTD or schema from X12 (though I understand that
work continues in that direction). This example is a very valid
one though one might wonder about the redundancy of transmitting an
element's description every time you transmit the element (some elements
such as "reference number" are sufficiently generic that they are used
in many, many places)...but I digress. Back to "could":
We've also seen from Joe Barten an entirely different approach to the
XML from X12 which, amazingly, provides one-to-one mapping (as does
Kevin's) but also preserves the X12 syntax within the XML
syntax.
Frankly I don't endorse either of these
approaches for different reasons. At the same time, this is not to
say that XML is bad, evil, invalid, or otherwise objectionable. As
Rachel Foerster points out, XML certainly can be more human-readable and
and more flexible (that flexibility really is a double-edged
sword).
Oh, and there was a second comment in Kevin's
note that I wanted to touch on: "Support for XML as mentioned in
several of these threads is imbedded in much of the software you
currently use such as MS Explorer, Outlook or Word." I'd just
offer a caveat here: This doesn't guarantee or imply that any
given application that "does XML" would have any idea what to do with
either of the examples (or any other XML, for that matter). Sure,
they can read it they can parse it, they can display it in a pretty,
hierarchical format (I've done this with various browsers including
Internet Explorer, Netscape and Mozilla with varying degrees of
success), but if the goal is to get the data out of the XML document and
into a database, as Rachel pointed out, both EDI and XML "still require
that the very time consuming, laborious mapping and syncing of semantics
be done by human beings."
One other aspect I've seen discussed with
regard to XML: Human-readability. XML does not guarantee
this. XML is more or less, just the framework, the syntax, the
rules on what data goes where (and to a limited degree, what format it
takes). It is up to the designer of the tags and the data
hierarchical relationships to ensure that humans can read it...if that
is an important goal. My question is: If our focus in on the
transfer of data from computer system A to computer system B without
either having particular knowledge about the other and without human
intervention (which is basically the goal of EDI), how important is
human readability in the underlying XML. If human readability is
truly desireable, and I'm sure in certain circumstances it is, then the
coupling of style-sheets with XML can provide much better
readability than raw XML does (again, good design goes a long
way...).
But enough philosophy.
8-)
Best regards,
Bill Chessman
Inovis(tm), Inc.
Ralph,
A simple way to think of it is this. EDI and X12N in
particular should be consider a form of a language. Just like with any
language you need syntax and rules that govern the syntax. Syntax
rules allow you to define structure of the language so there is
consistent interpretation of the structure. In X12 the syntax (aka
dialect) consist of terms such as Segment, Element, Mandatory,
Optional, Values, Loops. XML is no different. It too has a syntax
which governs it. In fact, XML is in essence a language for defining
languages or in other words a syntax for defining other syntax. It
stands for eXtensible Markup Language. It looks much like HTML in that
it has tags. For example, <ST_0010>. It has the ability for you
or anyone else to define your own syntax be defining what are known as
DTDs or Schemas that define structures much like the X12 IGs and
sample define the structures of X12 documents. Support for XML as
mentioned in several of these threads is imbedded in much of the
software you currently use such as MS Explorer, Outlook or Word.
Unlike HTML where the tags were used to define the use of the data XML
gives you the ability to define your own tag (aka element) names.
Which means you can define your own ML or Markup Language for your own
documents.
One thing that ties both syntax together at least should tie
them together is common meaning or semantics. Just like when you have
two people talking about the weather one speaking English and the
other speaking French you need a common set of terms and their
meanings to have a meaningful conversation. Of course a translator is
needed to convert back and forth from one dialect to the other. And
just like the pocket translator I carry when I head to Europe there
are translators that help convert from one dialect to the other such
as between X12 and XML. The tricky part is what form of
XML? Since XML in and of itself is nothing but a language which
you can use to create you own dialect you need to know what dialect or
standard of XML you want to use. This where much of the new battles
are being fought in this industry and every other one out there. That
is the race to define a dialect in XML for Healthcare. There are
several efforts going on and I participate in several of them along
with other industries and I see the same fights across them The syntax
itself is hard enough but you will find the same fights industries had
over when defining the X12 semantics you will find in the process of
defining XML dialects. Although the syntax between X12 and XML are
different their meaning are not. Here is a simple example of what a
small X12 document could look like in one example XML dialect but have
the exact same meaning :
ISA*00*
*00*
*ZZ*133052274
*ZZ*642460001
*010816*123
1*U*00401*000000001*0*T*^~GS*HC*133052274*642460001*20010816*1231*000000001*X*00
4010X096~ST*837*000000001~BHT*0019*00*1*
........
<?xml version="1.0"
encoding="UTF-8"?>
<Interchange>
<ISA desc="Interchange Control
Header">
<ISA01
desc="Authorization Information
Qualifier">00</ISA01>
<ISA02 desc="Authorization
Information">
</ISA02>
<ISA03
desc="Security Information
Qualifier">00</ISA03>
<ISA04 desc="Security
Information">
</ISA04>
<ISA05
desc="Interchange ID
Qualifier">ZZ</ISA05>
<ISA06 desc="Interchange Sender
ID">133052274
</ISA06>
<ISA07
desc="Interchange ID
Qualifier">ZZ</ISA07>
<ISA08 desc="Interchange Receiver
ID">642460001
</ISA08>
<ISA09
desc="Interchange
Date">010816</ISA09>
<ISA10 desc="Interchange
Time">1231</ISA10>
<ISA11 desc="Interchange Control Standards
Identifier">U</ISA11>
<ISA12 desc="Interchange Control Version
Number">00401</ISA12>
<ISA13 desc="Interchange Control
Number">000000001</ISA13>
<ISA14 desc="Acknowledgment
Requested">0</ISA14>
<ISA15 desc="Usage
Indicator">T</ISA15>
<ISA16 desc="Component Element
Separator">^</ISA16>
</ISA>
<Division>
<GS
desc="Functional Group
Header">
<GS01 desc="Functional Identifier
Code">HC</GS01>
<GS02 desc="Application Sender's
Code">133052274</GS02>
<GS03 desc="Application Receiver's
Code">642460001</GS03>
<GS04
desc="Date">20010816</GS04>
<GS05
desc="Time">1231</GS05>
<GS06 desc="Group Control
Number">000000001</GS06>
<GS07 desc="Responsible Agency
Code">X</GS07>
<GS08 desc="Version / Release / Industry Identifier
Code">004010X096</GS08>
</GS>
<Health_Care_Claim__Institutional>
<ST_0010 desc="Transaction Set
Header">
<ST01 desc="Transaction Set Identifier Code" valueDesc="Health Care
Claim">837</ST01>
<ST02 desc="Transaction Set Control
Number">000000001</ST02>
</ST_0010>
<BHT_0020 desc="Beginning of Hierarchical
Transaction">
<BHT01 desc="Hierarchical Structure Code" valueDesc="Information
Source, Subscriber,
Dependent">0019</BHT01>
<BHT02 desc="Transaction Set Purpose Code"
valueDesc="Original">00</BHT02>
<BHT03 desc="Originator Application Transaction
Identifier">1</BHT03>
<BHT04 desc="Transaction Set Creation
Date">20010816</BHT04>
<BHT05 desc="Transaction Set Creation
Time">1231</BHT05>
<BHT06 desc="Claim or Encounter Identifier"
valueDesc="Chargeable">CH</BHT06>
</BHT_0020>
NOTE : The preceding partial XML document is one example of a
dialect that could be used to represent the same data in an X12
document in XML syntax. the "desc" is called an ATTRIBUTE and
something the author of this dialect chose to add a description to
each of the elements. The author also chose to create a dialect that
mirrors the X12 syntax as close as possible for the purposes of
keeping the transition from one to the other as simple as possible.
You can find more about XML in general at http://www.w3.org/XML/ as well
as other industry specific websites that are pursuing their own
standard syntax based on it.
Kevin Day - Sr.
Program Manager
Vitria Technology, Inc.
www.vitria.com
945 Stewart Rd.
Sunnyvale, CA 94086
TEL :
408.212.2529
CELL : 408.368.7783
---
The
WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
These listservs should not be used for commercial marketing purposes or
discussion of specific vendor products and services. They also are not
intended to be used as a forum for personal disagreements or unprofessional
communication at any time.
You are currently subscribed to
wedi-transactions as: [EMAIL PROTECTED]
To unsubscribe from this
list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or
send a blank email to [EMAIL PROTECTED]
If
you need to unsubscribe but your current email address is not the same as the
address subscribed to the list, please use the Subscribe/Unsubscribe form at
http://subscribe.wedi.org
IMPORTANT NOTICE:
This message is intended only for the use of the
individual or entity to which it is addressed and may contain information that
is privileged, confidential and exempt from disclosure under applicable law.
If you have received this message in error,
you are hereby notified that we do not consent to any reading, dissemination,
distribution or copying of this message. If you have received this
communication in error, please notify the sender immediately and destroy the
transmitted information.
---
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time.
You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]
If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
|
