Martin and Marsha
Interesting! May I add my bit to a debate that is becoming stormy, high with emotions but bascially a genuine emotion of anguish. The comments below are in my individual capacity and do not reflect the view of my organization.
1. Free Stuff: Well we have to be fair to all the people who have put in volunteer work. All free stuff is what it is . It is available on "as is where is" conditions and it does give you a higher platform to take off from.
Thank you all those wonderful people who have put in their time and effort.
We also looked at the 837 Transactions on the Claredi Website and discovered that the "free" test files are indeed incomplete and at times incorrect.
( We are "one of the vendors who see this as a prime opportunity to perpetuate their revenue" but by not spreading FUDD ---but that is another story ! Also we wish Claredi the very best so they make their money and I guess we should not grudge them since thay have been on it for a long time !!).
I want to share the approach taken by us with a hope that it sheds more light on the issue.
3. Fundamental Issues - How to tame the X 12 EDI beast ?
a) The more fundamental issue is that the transaction standards evolved out of EDI a twenty-year-old technology.
HIPAA ASC X12N transactions are basically a new band aid paint job. Pressed by mandates HIPAA initiative advocates fast-forward with a creaking EDI technology and mind set. This forces implicitly antiquated thinking and old methodologies to solve the HIPAA problem.
b) What we have done is that we have "objectized" the the transaction entities into Elements, Segments, Loops ( and Regions which is our abstraction ). We were delighted to find out that there was indeed a method in the X 12 madness and our generic "object definitions" remained valid for all the X 12 N HIPAA transaction standards like 837, 835,275 et al. I am sure there are other folks who may have done this. So far not much to write home about except that it does make job of checking SNIP/WEDI Level 2 Compliance every easy and "almost" automatic.
Of course the wish is life would have been easier if the pdf standards were available in machine readable format which we could then simply plug in to the Level 1 & 2 SNIP/WEDI rule checker.
c) We also spent considerable time, effort, technology creation (and money)in modeling the business rules embodied in these standards. We again found out to our pleasant surprise that we could capture the rules of 837 Professional standard for example into set of 20 generic rules. These 20 rules are coded in appropriate machine readable format so that we can use the rules to validate upto Level 4 automatically and create events for checking Level 5, 6 and any other business rules.
The "machine readable" format that we use is XML. I did not use the word "XML" since it raises hackles in the traditional X 12 / EDI Camp and in one of the discussion forums I have been beaten black and blue.
We have found XML to be a convenient alphabet for modelling and but I could not care less. It could be in a spread sheet format or whatever.
d) Once we were able to model the X 12 Transaction Sets formally, it comes along with lots of freebies. For example element syntax checking can be "formally" demonstrated to be correct. Similarly the Level 4 rules can be demonstrated to be correct. However life has not been so simple. For example some of the rules seem to be "ambiguously" stated or it could be lack of our domain knowledge as applied to Health Care and Insurance.
e)You will also notice that some organizations take efforts to come out with their "versions" or data dictionaries of the the transactions which try to limit or define a sub set of the transactions. I am not sure whether this is right approach legally since HIPAA mandates that all Transactions have to be accepted if they are in the HIPAA format.
Moreover these data dictionaries again suffer from the same mind set - words, words and words which obfuscate the matter further.
f)Our modelling approach outlined above does make the X12 (EDI) standard intutive and simple. The approach is similar to having a higher level language to mask the non intutive but powerful assembly language ( X 12 ).
The troops in our ranch feel that the beast has been tamed. Bottom line - new folks can be inducted into the team without first requiring a Ph D. in EDI and X 12.
4. Routing Issues:
Enough is being said on this but I get an uneasy feeling that it is going to go the way of ISO 7 Level Communications model. It never took off. The more simple TCP/IP, Internet protocols took off because they were not essentially commitee driven.
Why should the mode of communications ( SMTP/FTP/VAN/HTTP or messaging like IBM MQ, Microsoft MSMQ or JMS) be linked to the address of the entities ? Why in the heavens is E mail addressing reliable? Use E mail as URL's and whether it gets communicated via FTP SMTP or whatever should be left to the entities. Looks heretic but doable (after drilling down into this idea). The email address need not have a person but could have an automatic process. Of course these are my views and I leave it to the "learned" commitee to decide.
Encryption - Give me a break. No one is going to spend $$$'s to break into a PHI of an individual. So for example go for 128 bit Encryption for PHI and let keys be exchanged as part of TPA and be done with it.
Let the information go over dial up, Internet or whatever. For other critical system information there is enough technology out there to take care of security.
5. Certification :
Totally concur with Martin. This is no mans land and free for all wild west scenario. We have written our parsers and validators and now we are having the ignominy of getting them validated from one of my competitors or start test my product the hard way.
I have reasons to believe that all vendors mean different things when they say that their products are "compliant" and they are not incorrect. Their is no "standard transaction test suite" which if you run will validate your software or a vendor product. The SNIP/WEDI document on various levels is absolutely insufficient, non-formal and does require leap of faith.
6. Last Word:
New technology can be applied to the X 12/EDI HIPAA problem if all of us look at problem from new technology mind set. ( I know I am going to be mauled for this statement -but so be it !).
Having said this and having spent my life in developing computing based systems I have learned the painful way that even very small systems have to be tested tested tested and tested. It does seem a leap of faith that when there is no agreement on what constitutes a stanard test suit how can there be an agreement on what contitues a HIPAA Compliant Transaction. I remember way back we use to vaildate Pascal Compiler against a test suit from some Australian University ( not free I guess !). But it was easy. Pascal was formally defined so validation could be demonstrated by formal techniques too.
Worst still there is no "formal public domain" language to model the transactions. And for valid reasons how would organisations which have spent time and money ( like mine and I am sure there are others) share this knowledge free of cost?
Yes all HIPAA folks are working very hard ; so let us hope we are going somewhere and not merely running on a tread mill and die of exhaustion.
Sanjeev N. Kulkarni
Chief Technical Officer
Advent Software Ltd.
+91-20-6119162
Martin Scholl <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: "Martin Scholl" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 23, 2002 10:59 PM
Subject: Re: HIPAA Compliance Tests
> Excuse me, Marsha!
> I just went in selfdoubt to the Claredi website--> Free stuff
> There were 50 837's under WEDI SNIP defined testfiles. They all have an
> error condition listed. Broken 837's in my lingo
> Under business scenarios where another 30 or so testfiles. Maybe I am
struck
> with blindness, but there are no 4,700 scenarios. There are another 100 +-
> transaction pending but no data available.
> Let me get on my soapbox too.
> I don't want to belittle anybody's effort or hurt their feelings for all
the
> volunteer work that they are doing. I am a member of MAHI, the
Mid-Atlantic
> Hipaa Initiative, the local WEDI-SNIP initiative. I know about volunteer
> efforts.
> But let's be for real here. In 1 1/2 years we want to move 14 % of GDP,
> Gross domestic product of the US of A, from various file formats and
paper
> to EDI. 9 Protocols for sure, more in the making. This is EDI, the most
> non-intuitive data format on earth. The average implementation for
Wal-Mart
> business partners takes 9 months before things work smoothly. The
> healthcare industry as a whole is supposed to make it in 18 months now.
> There are only very few testfiles out. Only of one transaction set. The
> routing group does not know at this point which information goes into the
> ISA header, to make sure routing will work. There is no national
repository
> for routing information. Is it Dial-up, ftp, VAN or what? Encryption with
> VAN, not with Dail-up. What encryption, PGP?? The transaction group is
now
> talking ebXML and CPP's while 9 out of 10 hospitals haven't even evaluated
> how they will handle HIPAA. Most providers have no idea about HIPAA. They
> trust their vendors. Some vendors have no clue, groping for knowledge in
> the same conferences that I go to, participating in the same email groups
> that I am in. HIPAA certification is a vague concept. Claredi is praying
to
> be the chosen one.
> Other vendors see this as a prime opportunity to perpetuate their revenue
> stream by spreading FUDD, fear, uncertainty and disinformation, to get
their
> customers hooked on a proprietary solution with a per transaction fee.
> HIPAA transaction sets, aka administrative simplification, are hard work.
> They take time to understand, more time to implement and even more to
test.
> Just having 50 broken 837's and 30 good ones is not going to make this
> transition work.
> It might very well be that there are forces in the government who have no
> interest in the success of HIPAA transaction sets. Who wish they would go
> the way of the metrification. You remember: In the 1970's this country by
> act of Congress went from the imperial system to the metric system. The
> last time I checked, the US and Burma alone in this world still measure
> distances in feet, weight in ounces, temperature in Fahrenheit. Don't be
> assured that a similar fate is not in store for the Clinton Healthcare
> reform. We all might be working our behinds off to get things ready, while
> Congress decides to grant one delay after the other until the issue goes
> away.
> I am not shy to do the heavy lifting, read the IG's , write parsers, test,
> tie in business rules and so on. But for an effort of this magnitude, I
> believe the equipment supplied so far, in the form of a few testfiles of
one
> out of 9 protocols make this a leap of faith.
> So, now I feel I can climb down from my soap box.
> Feel free to join in this discussion but please, lets not get into
personal
> attacks. We are all working hard.
>
> Martin Scholl
> Scholl Consulting Group, Inc.
> 301-924-5537 Tel
> 301-570-0139 Fax
> [EMAIL PROTECTED]
> www.SchollConsulting.com
>
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request.
