Rachel,
The statement I used that stated "Proving that application systems meet the new HIPAA business requirements..." was just a generic statement in lieu of writing a longer description and lengthier e-mail. What I meant by that statement was exactly what you wrote below without going into the description. Thank you for the clarification, I will make it a point to go into further detail when something could be construed as ambiguous or misunderstood. In regards to your statement "an entity only needs to demonstrate that it can generate a complying transaction or receive a complying transaction." , the HIPAA test cases and conditions still need to prove that new and regression business functionality is not impacted. This cannot be done by just proving the ability to send or receive a properly formatted file. Many CE's are struggling with creating the test cases to resemble existing and anticipated lines of business because they are either starting from an unknown (creating a test file using an EDI tool along with their interpretation of the (IG) and/or finishing with an unknown. i.e. - if the file passed or failed, did the test analyst map the test file properly or worse did they even know what the expected results were supposed to look like?). Also the process is going through several layers of translation, the analyst to the test file and then through the translator or middleware component most likely mapped by another analyst. This just scratches the surface but to me, there are just too many variables and not enough traceability when trying to conduct a proper test effort and correcting possible defects. The effect of this will lengthen test phases, test case preparation, testing timelines, and defect tracking and resolution to the point that deliverables will be late, implementation dates missed and mostly certainly a negative impact on already thin budgets. With a more quality assurance centric plan, CE's may avoid some of these pitfalls along the way, otherwise the 3rd and 4th quarters of 2003 will not be a pleasant experience for many CE's. Mark A Lott President HIPAA Testing, Inc. www.hipaatesting.com Office: 480-946-7200 Cell: 480-580-4415 Fax: 877-825-8309 "Advanced Testing and Certification of HIPAA Transaction Compliance" CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 1:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Testing for levels 3, 4, and 6 Mark, As an EDI and IT professional I agree with much of what you say below. However, there is one point that I disagree with...it's your statement that "Proving that application systems meet the new HIPAA business requirements..." is a HIPAA requirement. Actually, it's not....all that the law requires is that the transaction conform to the standard data content and the standard format, which is based on the X12 standards. What the internal apps do is irrelevant in terms of whether they have been remediated, replaced, or whatever. I don't mean to imply that backend apps must at some point either be remediated or replaced, but that is not a requirement of HIPAA. Thus, in order to "prove" compliance with the HIPAA Electronic Transactions Final Rule requirements, an entity only needs to demonstrate that it can generate a complying transaction or receive a complying transaction. Once that's been proven, the internal processing of the transaction data can be totally manual or semi-automated or totally automated. The law doesn't care. Of course, manual or semi-automated internal processing doesn't get one to administrative simplification, does it? But the law does NOT mandate that any covered entity redesign their internal business processes for cost reductions and/or simplification. Those of us that have been in the EDI game for a few decades know that just implementing an EDI capability doesn't create any business benefit UNLESS the internal business processes are redesigned as well. Re your comment about machine readable IGs - what a concept. This capability has existed for several years using the UN/EDIFACT IMPDEF message specification. IMPDEF was developed cooperatively between the UN/CEFACT and the X12 Committee and its specifically intended to be able to convey in machine readable syntax based on the international standard for EDI, which all good commercial translators should be able to process, an organization's implementation definition for any X12 transaction set or UN/EDIFACT message. Personally, my opinion is that it's a major shame that the HIPAA implementation guide specifications were made available ONLY in the Adobe .pdf format and not ALSO in the IMPDEF format for automated processing. Oh well...... BTW, a colleague of mine already has the HIPAA 270, 820, 834 and 835 ICs and a portion of the 837D in IMPDEF form. Rachel Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com ********************************************************************** 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. ====================================================== 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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
