Re: Route through email and attach EDI files
Ronald: I don't think EDI would necessarily have looked any different if it had been devised in the TCP/IP world. Look at MIME: it's not any prettier. If XML had been available from the outset, maybe EDI would have used XML for its syntax. But you have to admit there's nothing inherent in the syntax of ANSI ASC X12 or UN/EDIFACT that keeps EDI from being a first-class Internet passenger. Peter Barry has suggested that payers with elaborate, web-based DDE services could allow providers to upload standard X12 interchanges right into a field in the DDE system, presumably wrapping EDI in MIME for an HTTP POST or something like that. And high tech messaging services like ebXML MS don't care whether they're carrying payloads of X12 or XML. The HIPAA standard transactions based on X12 and NCPDP already exist (and maybe new interactive ones based on the UN/EDIFACT syntax will be added into the mix later), and we can't do anything about it even if we wanted to. We should concentrate on devising recommendations for means of routing these packages safely, securely and reliably. If the next incarnation of HIPAA standard messages were based on XML schemas or core components, we'd still be left with the same problems we have today: how to get the claim to the payer, or the remittance to the provider. If we had a Healthcare CPP and Registry, they would work out-of-the-box for XML just as well as for EDI - trust me. EDI's market acceptance has nothing to do with the protocols it's built on: the syntax (ASC X12.5 and X12.6, ISO 9735 or XML) is the simple part - the semantics are difficult. FTP, SMTP, MIME and other Internet protocols have far fewer variables to deal with, and hence are simpler to interoperate. But I'll grant you one thing: if the (Healthcare) world were standardized on a single transport layer (TCP/IP), it would make things far less painful. For example, we wouldn't have much work left to do to customize the CPP DeliveryChannel, as it's already designed around TCP/IP protocols like HTTP and SMTP. And I certainly agree that there should be no need to duplicate the sender identification effort with another login process much like BBS's and FTP require. You should only have to logon once to your own ISP, VAN or CH, and not duplicate that process for every payer you might conceivably access; that's the whole point of eliminating payer-centric mailboxes. As an aside, Open Source isn't the answer to all that ails us. Most of us don't still live at home with Mom, and therefore we have to charge for our labor. Open Source is often a model which works well for hardware manufacturers (i.e., using Open Source infrastructure software to encourage development for their platform), but I've never seen it applied to e-commerce applications. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Ronald Bowron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 21 June, 2002 01:39 PM Subject: Re: Route through email and attach EDI files As a long time fan of efficient transfer of business data (i.e. EDI vs. XML), I've often wondered why the Open Source community has never taken EDI under it's wing like they have other services (FTP, SMTP, Telnet). I guess the market wasn't there. Anyway, to keep in line with our efforts, I've always wondered what EDI would be like if it were developed in the TCP/IP world vs. the legacy BBS (async protocols) VAN (SNA/Bysnc protocols) world. I've also believed that part of the reason other application or file transfer protocols (FTP, SMTP, XML) seem to gain wider acceptance more rapidly than EDI is simply that they've standardized on a single transport layer (TCP/IP). So I ponder on this as I look out over the issues raised in this forum. Can a standard interface be developed that would work much like SMTP but without all the overhead of another addressing schema? Imagine if an EDI client application were built in the open source community (much like SendMail), that when given the EDI filename, would access the ISA Header and GS segment, use that information to locate (Either via ACL, LDAP, DSML, ebXML/CPP) in an ID Repository the proper destination and communication method and protocol (of course today, the TCP/IP protocol would be nice). The EDI Server (much like an SMTP Server) would acknowledge the EDI Client request, (assuming TCP/IP) establish a VPN or SSL channel (for encryption purposes) and validate digital certificates, and then receive the ISA header. Verify the Sender/Receiver information, and request the GS segment. From there, the GS segment would be used by the EDI Server to set the Functional processing of the transactions (Realtime/Fast-Batch/Batch) and send the I/O stream on its way to the appropriate application service queues or simply stored as a file. So basically, all the necessary information to login the user, determine what they are needing to do is in the ISA and GS segments
Re: Route through email and attach EDI files
Martin: Your e-mail was lost in-between all the stuff about Kennedy's new bill, Gartner's supposed opinion of ebXML, bio-defense and WebMD's stock woes. I now see that your missive actually was very relevant to what we're doing here in the ID Routing group, which is why it was easily overlooked. Imagine that someone is actually thinking about EDI Addresses, rather than big strategic issues! As I mentioned Wednesday, payers at the other end have to support e-mail in exactly the same way; otherwise your PMS can't talk to them, and it won't be worth devising constructs for describing those techniques in the EDI Address. But surely some payers (or intermediary CHs) do (or will) support e-mail, and perhaps you can find out the particulars of the way they implement SMTP portals (and please share the details with this group). Are you familiar with EDIINT (Electronic Data Interchange-Internet Integration)? Not that you may necessarily want to support EDIINT in your software system, but the EDIINT specification will give you some useful background when devising requirements for EDI Addresses pertaining to (regular) e-mail. Take a look at http://www.ietf.org/html.charters/ediint-charter.html, specifically the Internet-Draft for MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. Perhaps instead of defining stuff in the CPP, assumptions can be made about attachments based on Content-Type and other junk directly in the S/MIME. Additionally, the certificate (public key) itself might give information about encryption algorithms supported by the recipient - in other words, once you've pointed to the certificate in your CPP, you've said all there is to say about how stuff is to be encrypted. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Martin Scholl [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Monday, 17 June, 2002 08:21 PM Subject: Re: Route through email and attach EDI files William, thanks for your in-depth analysis of the email aspect. I like your description of push versus pull. This stresses one of the main advantages of the email route. I have not really followed the ebXML thread much. All I understand is that its aim is to communicate a set of Trading Partner parameters in a response to a standard XML query. For email we would need something like this email address email address/address maxsize maximal mbytes of attachemnts /maxsize maxnumber maximal number of attachments /maxnumber encryption yesno Yes No Always Sometimes/yesno typePGP or whatever/type publicKey Public Key /publicKey /encryption /email This is my first stab at this, please, anyone amend/delete at your liking and feed it back to the group Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com
Re: Route through email and attach EDI files
For payers it might be easy to decide on their Internet strategy. I represent a Provider Software Vendor, offering Browser based interface. We have no choice but to design a system that will handle all ftp, smtp, http and any other vendor specific methods to make sure that provider claims (and transactions) reach payers. Moreover, Final Security Regulations might completely changes the choices available for transaction routing. All this talk about transaction routing, appear like a *dark tunnel*. What internet and routing strategy should be adopted by a web based provider software vendor like us? I believe there will be many like us in the industry offering practice management software to doctors; what are they planning for routing treansactions? Any *ray of hope* will be appreciated. Deepan Vashi www.ipmsolution.com Efficient Healthcare Delivery and Practice Management - Original Message - From: Martin Scholl [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 5:51 AM Subject: Re: Route through email and attach EDI files William, thanks for your in-depth analysis of the email aspect. I like your description of push versus pull. This stresses one of the main advantages of the email route. I have not really followed the ebXML thread much. All I understand is that its aim is to communicate a set of Trading Partner parameters in a response to a standard XML query. For email we would need something like this email address email address/address maxsize maximal mbytes of attachemnts /maxsize maxnumber maximal number of attachments /maxnumber encryption yesno Yes No Always Sometimes/yesno typePGP or whatever/type publicKey Public Key /publicKey /encryption /email This is my first stab at this, please, anyone amend/delete at your liking and feed it back to the group Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com . - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Monday, June 17, 2002 11:43 AM Subject: Re: Route through email and attach EDI files Martin: E-mail is an excellent model which shows up some of the inherent disadvantages of the payer-centric mailbox system we have today. I don't go to the sender's server to retrieve my e-mail - it's pushed to me. I only have to remember my incoming POP3 mail server name or address, the outgoing SMTP server name or address, my logon and password, and various authentication and port settings of my one or few mailboxes (maintained on my server or at my ISP). Accordingly, I need only poll my one (or few) mailboxes. If I tire of the bad service or impertinence of a particular ISP, I switch to another one. This is flexibility that payers and providers should demand when moving around standard transactions. Now imagine if e-mail were built around the payer-centric, or pull model: I'd have to have e-mail client account settings to access the mail server for anyone I ever anticipated receiving mail from! I would have to arrange - through an out-of-band channel - for server names, passwords, port settings, and so on, with each and every correspondent. Actually I wouldn't: I probably would just use the U.S.P.S. Indeed, e-mail is also a very viable option for the transport of standard transactions; it (SMTP) is definitely one of the supported delivery channels for both EDIINT (AS1) and ebXML. But as Cory Dekker reminded us, e-mail is not quite the answer to all which ails us. Realtime or fastbatch processing will probably require more exotic transport methods, like HTTP and SOAP. We'll have to account for any technique likely to be used by any two partners when designing the EDI Address (DeliveryChannel) component of the CPP electronic partner profile. Actually, we may only have to enumerate them: the OASIS ebXML CPP/A Technical Committee will probably be able to help us with the meat of the definitions if we can just tell them our requirements. Perhaps you could start by listing the combinations you see needed for using e-mail to transport interchanges; in the body or as an attachment; zipped or unzipped; S/MIME or PGP/MIME; etc., etc. The advantage of EDIINT AS1 is that one only has to say he's using that standard with a few variables, and all the detail will be understood by the other end; it also provides a formal model for acknowledgements not available with ordinary e-mail. By the way, the metric system has been legal (though not mandatory) in the U.S. since 1866. In any case, the metric vs. English system dichotomy is not an apt analogy to HIPAA. We have a working system of weights and measures - even if the English is demonstrably
Re: Route through email and attach EDI files
Deepan: Assuming your Practice Management System processes HIPAA standard transactions, and you intend to transport point-to-point, then I guess you have no choice but to support most conceivable means (protocol and packaging) of sending and receiving interchanges. An alternative is to support just the more common methods (whatever they are in healthcare: we need to determine this), and then encourage your customer to use a VAN or clearinghouse as an intermediary if the payer requires anything weird (e.g., 3780 BSC). Your core-competency is probably not communications software, so it's possible you're limited to the protocols supported in whatever third-party comm package you've perhaps integrated into your system. Just like with the Cleos, IpSwitches and EDIINT packages of the world, your customers will have onerous manual setup for each of their payers. I hate modems and comm settings (and printers), so I am only too relieved to have a single Internet connection to the world - that simplifies things quite a bit. But even with the internet (FTP, SMTP and HTTP) and the payer-centric mailbox model, there's still manual setup for each payer required. Eventually, if every payer (or their CH proxy) supported the CPP, you could write your software so your customer would be able to insert the CPP (Electronic Partner Profile) to auto-configure the communications settings. And then even later on, your software could be made smart enough to search the Healthcare CPP Registry so CPPs wouldn't have to be manually handled. That's the vision thing, anyway. In the meantime, you're on your own. So to help us out in determining requirements for the EDI address (DeliveryChannel) part of the CPP, perhaps you could give us the details of communication methods demanded in your marketspace - in effect, the protocols supported by payers. We need meat and detail. I vaguely know there're some common ones supported by payers (e.g., XMODEM, XMODEM-1K, YMODEM, YMODEM-G, ZMODEM, etc. etc.), all requiring dial-up into the payer's system. Will payers and CHs be supporting SMTP, EDIINT, FTP or HTTP over the Internet? If so, please share the details. These aren't competitive trade secrets. This is also an invitation to payers and clearinghouses to share their supported communication protocols. Again, if you and Julie Thompson really have reason to think the Final Security regulations might completely change the choices available for transaction routing, tell me what you believe - if only your speculation - and your rationale for believing so. I'm not a mind-reader, and would prefer to work with detail rather than vague pronouncements. I doubt seriously that any of the final regulations will specify (or disallow) particular transport methods, or change the requirement that encryption be used when transmitting PHI over the public Internet. Common sense will dictate that encryption excludes home-grown cipher techniques, whether or not explicitly stated in the regs: it would be irresponsible to use any but peer-reviewed encryption algorithms (in effect, standards such as the symmetric IDEA, RC2, RC4, DES, DES3 and Blowfish, and the asymmetric RSA), or PGP and X.509 PKIs. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Deepan Vashi [EMAIL PROTECTED] To: Martin Scholl [EMAIL PROTECTED]; William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, 18 June, 2002 05:05 AM Subject: Re: Route through email and attach EDI files For payers it might be easy to decide on their Internet strategy. I represent a Provider Software Vendor, offering Browser based interface. We have no choice but to design a system that will handle all ftp, smtp, http and any other vendor specific methods to make sure that provider claims (and transactions) reach payers. Moreover, Final Security Regulations might completely changes the choices available for transaction routing. All this talk about transaction routing, appear like a *dark tunnel*. What internet and routing strategy should be adopted by a web based provider software vendor like us? I believe there will be many like us in the industry offering practice management software to doctors; what are they planning for routing treansactions? Any *ray of hope* will be appreciated. Deepan Vashi www.ipmsolution.com Efficient Healthcare Delivery and Practice Management
Re: Route through email and attach EDI files
Well Dave,
Sure it is possible to use the body of the email
for the transmission. You can concoct a gruel email with multiple transaction
sets of differing code set innumerous groups all into one ISA
envelope. That thing would be so ugly, you wouldn't even have to encrypt
it :-)
But kidding aside, I think attachements make
EDI more manageable. You can have several attachments to one email, you
can open the email and see that there are attachments, it makes it just
clearer. And clear and simple is what we need urgently.
Also, call me an anarchist, but I really don't care
much for the realtime requirement of the 270/271 exchange. 2 to 30 seconds seems
so arbitrary. Can your database even handle that? What if it takes 31 seconds?
Will the HIPAA police come at 2 am, knock at your door and ship you to a navy
brigg? I doubt it.
But what I don't doubt is that if we don't make
HIPAA EDI easily adoptable with common sense solutions, then HIPAA will go the
way of metrification. Remember the 70's, when the US by law adopted the
metric system? It went nowhere. We still deal with feet, inches, gallons and
send Mars probes crashing into orbits below the surface.
HIPAA transactions could easily go the same
way. If the politicians in November 2003 see the healthcare delivery
threatened by overly bureaucratic demands, then HIPAA will be rescinded faster
then we can say "EDI". Then all our efforts will be in vain and the
considerable investment in time and money would never result in a
pay-back.
That's why I propose email as a viable solution for
routing.We can still investigate CPP and ebXML, VANs and ftp, CDs with
FedEx, Floppies with bike messenger but email is here to stay.Providers
would not need a clearinghouse and pay an extra per-transaction
fee.
It's Saturday and my wife gives me the evil eye for
working. Let's keep this discussion going next week,
Martin SchollScholl Consulting Group,
Inc.301-924-5537 Tel301-570-0139 Fax[EMAIL PROTECTED]www.SchollConsulting.com
- Original Message -
From:
David A.
Feinberg, C.D.P.
To: [EMAIL PROTECTED]
Sent: Saturday, June 15, 2002 1:49
AM
Subject: Re: Route through email and
attach EDI files
Paul, Martin, Cory, et.
al.,
Since it's been a verrry long day
this Friday, and I'm on a bit of a roll, allow me to raise the ante another
nickel.
Since X12 [and HL7] transactions
are strictly ASCII text, who needs attachments?
Happy weekend.
Dave Feinberg
Rensis Corporation [A Consulting Company]
206-617-1717
[EMAIL PROTECTED]
- Original Message -
From:
Paul
Weber
To: [EMAIL PROTECTED] ; [EMAIL PROTECTED]
Sent: Friday, June 14, 2002 8:35
AM
Subject: Re: Route through email and
attach EDI files
I see Martin's 2 cents and raise a nickle. He makes a good point ---
especially for small volume batches. However where things get dicey is when
attachments start getting too large to get through firewalls and/or
negatively impact network performance. For example, I worked for a large
west coast HMO that had a 1.5MB limit on attachments. We did a lot of secure
e-mailing of capitated patient rosters to IPAs and medical groups. Some of
these were too big to go through the firewall so we either broke them up
into smaller files or (horrors!) burned CDs.
Paul Weber
[EMAIL PROTECTED]-
Original Message -From: Martin Scholl
<[EMAIL PROTECTED]>Date: Thu, 13 Jun 2002 15:39:29 -0400To:
WEDi/SNIP ID Routing <[EMAIL PROTECTED]>Subject: Route through
email and attach EDI filesContent-Type: text/html;
charset=iso-8859-1
After following the discussion now for a few
months I begin to believe that we have not solved routing, one of
themost basic issues of EDI. All this talk about CPP and ebXML makes
my head spin; and to be honest, having my hands full with transaction sets,
I don't see myself studying now XML too.
Why don't we use email as the preferred mode of
routing?
This would solve most problems.
email is secure. Encrypting email with
PGP, Pretty Good Privacy is cheap, proven and common place
Attachments can be relatively large, mega
bytes if need be and numerous too
routing of emailis long solved and works
great as we all know
Identifiers are left between you and your
trading partner. We don't have to invent or find a unique ID as long
it is 15 digits long.
virus filters and such are widely available
and HIPAA Security can be attained at low costs
By having a robot check the inbox every minute
or so, "realtime" or something reasonably close to that can be
achieved.
TA1, 997,271,277 .are send back as
a
RE: Route through email and attach EDI files
Routing decisions may ultimately be based on two strategic issues: 1) The overall corporate internet strategy 2) Final Security Regulations may ultimately have an impact on the choices available for transaction routing Julie A. Thompson, Vice President http://www.concio.com -Original Message- From: Martin Scholl To: David A. Feinberg, C.D.P.; WEDi/SNIP ID Routing Sent: 6/15/02 6:24 AM Subject: Re: Route through email and attach EDI files Well Dave, Sure it is possible to use the body of the email for the transmission. You can concoct a gruel email with multiple transaction sets of differing code set in numerous groups all into one ISA envelope. That thing would be so ugly, you wouldn't even have to encrypt it :-) But kidding aside, I think attachements make EDI more manageable. You can have several attachments to one email, you can open the email and see that there are attachments, it makes it just clearer. And clear and simple is what we need urgently. Also, call me an anarchist, but I really don't care much for the realtime requirement of the 270/271 exchange. 2 to 30 seconds seems so arbitrary. Can your database even handle that? What if it takes 31 seconds? Will the HIPAA police come at 2 am, knock at your door and ship you to a navy brigg? I doubt it. But what I don't doubt is that if we don't make HIPAA EDI easily adoptable with common sense solutions, then HIPAA will go the way of metrification. Remember the 70's, when the US by law adopted the metric system? It went nowhere. We still deal with feet, inches, gallons and send Mars probes crashing into orbits below the surface. HIPAA transactions could easily go the same way. If the politicians in November 2003 see the healthcare delivery threatened by overly bureaucratic demands, then HIPAA will be rescinded faster then we can say EDI. Then all our efforts will be in vain and the considerable investment in time and money would never result in a pay-back. That's why I propose email as a viable solution for routing. We can still investigate CPP and ebXML, VANs and ftp, CDs with FedEx, Floppies with bike messenger but email is here to stay. Providers would not need a clearinghouse and pay an extra per-transaction fee. It's Saturday and my wife gives me the evil eye for working. Let's keep this discussion going next week, Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com - Original Message - From: David A. Feinberg, C.D.P. To: [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 1:49 AM Subject: Re: Route through email and attach EDI files Paul, Martin, Cory, et. al., Since it's been a verrry long day this Friday, and I'm on a bit of a roll, allow me to raise the ante another nickel. Since X12 [and HL7] transactions are strictly ASCII text, who needs attachments? Happy weekend. Dave Feinberg Rensis Corporation [A Consulting Company] 206-617-1717 [EMAIL PROTECTED] - Original Message - From: Paul Weber To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Friday, June 14, 2002 8:35 AM Subject: Re: Route through email and attach EDI files I see Martin's 2 cents and raise a nickle. He makes a good point --- especially for small volume batches. However where things get dicey is when attachments start getting too large to get through firewalls and/or negatively impact network performance. For example, I worked for a large west coast HMO that had a 1.5MB limit on attachments. We did a lot of secure e-mailing of capitated patient rosters to IPAs and medical groups. Some of these were too big to go through the firewall so we either broke them up into smaller files or (horrors!) burned CDs. Paul Weber [EMAIL PROTECTED] - Original Message - From: Martin Scholl Date: Thu, 13 Jun 2002 15:39:29 -0400 To: WEDi/SNIP ID Routing Subject: Route through email and attach EDI files Content-Type: text/html; charset=iso-8859-1 After following the discussion now for a few months I begin to believe that we have not solved routing, one of the most basic issues of EDI. All this talk about CPP and ebXML makes my head spin; and to be honest, having my hands full with transaction sets, I don't see myself studying now XML too. Why don't we use email as the preferred mode of routing? This would solve most problems. * email is secure. Encrypting email with PGP, Pretty Good Privacy is cheap, proven and common place * Attachments can be relatively large, mega bytes if need be and numerous too * routing of email is long solved and works great as we all know * Identifiers are left between you and your trading partner. We don't have to invent or find a unique ID as long it is 15 digits long. * virus filters and such are widely available and HIPAA Security can be attained at low costs * By having a robot
RE: Route through email and attach EDI files
Title: Message
I
think that this e-mail was intended for the entire
ListServ...
"Does
HIPAA address [transport protocol recommendations]?" - Not to my
knowledge. I believe it is painfully silent in this
area.
"Do
Payers expect Providers to reach them using different methods?" - Expect is a
strong term. Working for a Payer, we're hoping to provide a spectrum of
methods for transmission transport, including Secure FTP, Secure E-mail, HTTPS,
and possibly1 or 2 other custom methods (on private network lines).
We're looking at doing real-time transactionson the HTTPS and private-line
methods. We currently have no plans for an "Open" EDI Portal, though we
are keeping design considerations in mind as wemature our "private" EDI
Portal. Currently, access to the private Portalis managed through a
non-automated Trading Partner Agreement process. We are very interested in
what the Routing ID group is doing/planning, even though we probably
won'thave an CPP/CPA/ebXML method operational by H-day. We're taking
things one step at a time (mostly for cost reasons), but we do see an Open
Portal as one of the potential steps, down the road.
As for
consensus... I suggest checking the Archives... maybe I missed
it...
-Cory
Cory Dekker GWL-EBIS HIPAA Project Analyst
303/737-2022 or 303/522-8804
(Cell)
-Original Message-From: Deepan Vashi
[mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 7:58
AMTo: Dekker, CorySubject: Re: Route through email and
attach EDI files
Dear Martin Cory
From Provider's perspective are we looking at
multiple routing mechanism ?
1) Using modem and telephone lines for Medicare
(FTP is not permitted as per Medicare manual)
2) E-mail for some providers
3) FTP
4) VPN solutions.
List will grow depending on requirements of
Payers.
Does HIPAA address these issues ?
My Question is to leading Payer
Organizations: " Do Payers expect Providers (Doctors) to reach them
using different methods ?" : Is their any consensus ?
Regards
Deepan
- Original Message -
From:
Dekker,
Cory
To: WEDi/SNIP ID Routing
Sent: Friday, June 14, 2002 5:08
AM
Subject: RE: Route through email and
attach EDI files
I'd think that e-mail is one viable mechanism for a
small-volume batch arrangement. We plan to use it as
suchwithat least one TP.
However, I suspect that e-mail falls well short of
the "2 to 30-seconds" definition for real-time [4010X092 270/271 IG; page
14, 4th paragraph, "Real Time Transactions ... should not exceed one
minute"], and it probably represents a dis-incentive if the payer also
supports a real-time Web or DDE interface.
I'd say "close ... but no cigar" as a complete
HIPAA routing solution.
-Cory
Cory Dekker
GWL-EBIS HIPAA Project
Analyst 303/737-2022 or 303/522-8804 (Cell)
-Original Message-From: Martin
Scholl [mailto:[EMAIL PROTECTED]] Sent: Thursday, June
13, 2002 1:39 PMTo: WEDi/SNIP ID
RoutingSubject: Route through email and attach EDI
files
After following the discussion now for a few
months I begin to believe that we have not solved routing, one of
themost basic issues of EDI. All this talk about CPP and ebXML makes
my head spin; and to be honest, having my hands full with transaction
sets, I don't see myself studying now XML too.
Why don't we use email as the preferred mode
of routing?
This would solve most problems.
email is secure. Encrypting email with
PGP, Pretty Good Privacy is cheap, proven and common place
Attachments can be relatively large, mega
bytes if need be and numerous too
routing of emailis long solved and
works great as we all know
Identifiers are left between you and your
trading partner. We don't have to invent or find a unique ID as
long it is 15 digits long.
virus filters and such are widely available
and HIPAA Security can be attained at low costs
By having a robot check the inbox every
minute or so, "realtime" or something reasonably close to that can be
achieved.
TA1, 997,271,277 .are send back as
an attachment
You can also send back the detailed analysis
information. EDI compliance checker softwareproduces verbose
output and when you send that back in the body of theemail to the
message provider, you can give near instant feedback and go through the
training and testing phase faster.
Off course, if you need to submit 10gig of
EDI to CMS, this does not work, but for the traffic between providers
Re: Route through email and attach EDI files
Paul, Martin, Cory, et. al., Since it's been a verrry long day this Friday, and I'm on a bit of a roll, allow me to raise the ante another nickel. Since X12 [and HL7] transactions are strictly ASCII text, who needs attachments? Happy weekend. Dave Feinberg Rensis Corporation [A Consulting Company] 206-617-1717 [EMAIL PROTECTED] - Original Message - From: Paul Weber To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Friday, June 14, 2002 8:35 AM Subject: Re: Route through email and attach EDI files I see Martin's 2 cents and raise a nickle. He makes a good point --- especially for small volume batches. However where things get dicey is when attachments start getting too large to get through firewalls and/or negatively impact network performance. For example, I worked for a large west coast HMO that had a 1.5MB limit on attachments. We did a lot of secure e-mailing of capitated patient rosters to IPAs and medical groups. Some of these were too big to go through the firewall so we either broke them up into smaller files or (horrors!) burned CDs. Paul Weber [EMAIL PROTECTED]- Original Message -From: Martin Scholl <[EMAIL PROTECTED]>Date: Thu, 13 Jun 2002 15:39:29 -0400To: WEDi/SNIP ID Routing <[EMAIL PROTECTED]>Subject: Route through email and attach EDI filesContent-Type: text/html; charset=iso-8859-1 After following the discussion now for a few months I begin to believe that we have not solved routing, one of themost basic issues of EDI. All this talk about CPP and ebXML makes my head spin; and to be honest, having my hands full with transaction sets, I don't see myself studying now XML too. Why don't we use email as the preferred mode of routing? This would solve most problems. email is secure. Encrypting email with PGP, Pretty Good Privacy is cheap, proven and common place Attachments can be relatively large, mega bytes if need be and numerous too routing of emailis long solved and works great as we all know Identifiers are left between you and your trading partner. We don't have to invent or find a unique ID as long it is 15 digits long. virus filters and such are widely available and HIPAA Security can be attained at low costs By having a robot check the inbox every minute or so, "realtime" or something reasonably close to that can be achieved. TA1, 997,271,277 .are send back as an attachment You can also send back the detailed analysis information. EDI compliance checker softwareproduces verbose output and when you send that back in the body of theemail to the message provider, you can give near instant feedback and go through the training and testing phase faster. Off course, if you need to submit 10gig of EDI to CMS, this does not work, but for the traffic between providers and payers, email would solve the routing question I just started to test my payer oriented software with a provider softwarehouse in India. We tried ftp and were frustrated.Wewere fighting firewall issues, I had power outages and my server was down, my IP lease expired andIndia is about 12 hours ahead of meso thatwe could never communicatein real time. Movingthe communications over to email solved all these problems andnow we can concentrate ontransaction set issues. My 2cents Martin SchollScholl Consulting Group, Inc.301-924-5537 Tel301-570-0139 Fax[EMAIL PROTECTED]www.SchollConsulting.com--
