Rachel: I'm sorry, I misunderstood. I kept seeing "software developers," or their pronoun, in your response to Michael Mattias. I thought you were talking about software development.
Anyway, plenty of problems have been discussed in the last few months. And for the benefit of new folks who have subscribed recently, I'll list a few that come to mind: (1) How would a provider know where to even send a standard transaction to whatever entity handles them on behalf of the plan or payer? (2) A payer might have multiple "portals" for different types of transactions (say, "real-time" vs. batch) - how does he convey that to any provider who might want to send standard transactions? (3) How does a payer know whether a provider even supports EDI in the first place? (4) Assuming a provider *does* EDI, how would a payer know that a particular provider supports particular transactions (e.g, an 835 EOB - there's nothing in the 837 which says 835s are expected in return). Where would the payer send the transactions? (5) How would a payer or provider tell trading partners the communication protocols he supports? If he's using some of dial-up system, how does he convey logon IDs and passwords? Where does his X.509 digital ID public key reside? (6) How does a payer say what his requirements are for ISA and GS fields? How can he tell the provider that he can't handle more than 5000 claims in an individual 837? (7) How does someone report errors beyond the standard TA1 and 997? Does he support the 824? Or e-mail? - if so, what e-mail address should be used for sending error messages? You can add "or his agent" (such as a Clearinghouse, repricer or Third Party Administrator) to "provider" or "payer" above. This list certainly isn't exhaustive - I'm not the keenest when it comes to keeping crap organized, and Microsoft Project would only confuse me. Any of these problems can be solved the old fashioned way: through telephone calls, e-mail and paper TPAs. They can sometimes be delegated to one's Clearinghouse. On the other hand, if we agree that paper TPAs, paper "Companion" documents and lots of e-mail and phone tag are undesirable, we might ask if any or all of these problems can be solved in an automated fashion. Or - along the road to complete automation of EDI enrollment - can this information be advertised somehow where partners know where to look? Can it be expressed in a mechanical fashion for consistency and rudimentary automation? Do you agree that these are problems at least some payers and providers would like to see resolved? If any of these struck a chord, then our proposed solution - which entails recommendations based on the open ebXML CPP (electronic Partner Profile) and Registry specifications - seems to satisfy many of the requirements posed by the problems. Do you have alternative solutions? Are these problems so critical to solve that a solution has to be in place by April 2003? If these aren't problems at all and we've overlooked something obvious, let us know - we can wrap this up more quickly as I'm sure most of us are not interested in self-perpetuating standards projects. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Thursday, 09 May, 2002 04:04 PM Subject: RE: CPP Data elements draft for comment William, I don't believe my comments inferred that this group is developing software. My comments inferred that it's not the software developers that determine requirements. Rather, its the business users that must first determine/specify their requirements that can then be turned into functional requirements for software developers. My question was and still remains that trying to determine new data elements for the ebXML CPP spec is a bit premature without first having determined what the requirements (as yet not specified) to solve a problem (as yet undefined) for HIPAA electronic transactions implementation by the required compliance dates. Seems to be there are several carts in front of a horse here. Rachel -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 08, 2002 8:11 AM To: WEDi/SNIP ID & Routing Subject: Re: CPP Data elements draft for comment Rachel: We're not developing software. We're developing recommendations for the use of the ebXML Registry and CPP (Electronic Partner Profile) in the HIPAA Healthcare arena. Admittedly, there's a lot of similarity between software development and standards development, but that point needs to be clarified. Additionally, we would hope that any software needed to implement our recommendations would be available off-the-shelf, from ebXML (or EDI Translator) software vendors. The only "software" that this group might conceivably "develop" are non-normative XSLT style-sheets which can be used to render the Healthcare CPP in a human-readable format on any Web browser. Many folks on this list have contributed what, in effect, are "requirements." It would help if the requirements were organized, normalized and prioritized in the working papers. But we have requirements, nonetheless. For example, Kepa has raised the issue of certification capabilities, and I see that Chris Feahr, Dick Brooks and Dave Minch have added stuff pertaining to certification to their "Elements of the Healthcare Collaboration-Protocol Profile (CPP)." Whether a few field names really satisfy the "requirement" is another matter, but it looks like the requirement wasn't forgotten. Sometimes a spreadsheet is kind of clumsy for expressing relationships, but I know that Chris - bless him - has even been futzing with a UML diagram; see http://www.novannet.com/wedi/Healthcare_CPP_Model.jpg. Developing the spreadsheet is an integral part of enumerating requirements: what's the problem? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDI/SNIP Listserve'" <[EMAIL PROTECTED]> Sent: Tuesday, 07 May, 2002 11:34 AM Subject: RE: CPP Data elements draft for comment Michael, We should be asking the **real** users how they want to conduct business (= requirements!!!) Then the software developers should provide solutions to enable the business requirements. Software developers should not/are not capable of determining the business requirements and the business process requirements. They only provide solutions that enable the process to execute to the determined/expected outcome or deal appropriately with exceptions. Rachel
