|
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.
|
