Dick, I agree with the idea of having our CPP simply support the exchange of an EDI message file at this point. I just wondered whether we wanted to describe or try to diagram/model the related business processes in the white paper. Thinking about the process model (like the one Dave Minch created) is certainly helpful in coming up with the required list of CPP data elements, but it may not be necessary to describe all that in the paper... at least not in great detail.
BTW, I didn't realize that I could not attach files to messages on this listserv, so I'll have to find a place to put the spreadsheet for download. -Chris At 04:18 PM 5/4/02 -0500, Dick Brooks wrote: >Chris, > >I believe it depends on how complicated we want to get. I see two general >tracks we could follow: >1. Define a CPP that contains "knowledge" of the upper level business >functions (e.g. Enrollment/Request, Enrollment/Response) >2. Define a simple file transfer process to send/receive "files" containing >business transactions. > >Option 1 requires that we define a protocol engine/state machine for each >business process. > >Option 2 is isolated from the actual business process for which the business >data is intended. IMO, this is a much simpler "starting point" to achieve >and is less "challenging" to implement across the board. > >I propose that we learn to walk first by defining a simple "file exchange" >business process that will allow organizations to exchange HIPAA compliant >transaction files (per one of my earlier e-mails). There is nothing to >prevent implementers from evolving their systems to become more integral >with actual business processes (e.g. real time enrollments) in the future, >but this is much more challenging achievement. > > >Dick Brooks >Systrends, Inc >7855 South River Parkway, Suite 111 >Tempe, Arizona 85284 >Web: www.systrends.com <http://www.systrends.com> >Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 > > >-----Original Message----- >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] >Sent: Saturday, May 04, 2002 3:37 PM >To: [EMAIL PROTECTED]; Marcallee Jackson; Dick Brooks; Dave Minch; >[EMAIL PROTECTED] >Cc: William J. Kammerer >Subject: RE: our section of the paper > > >Dick and William (and group), >I'm attaching an Excel spreadsheet with a first-cut at a CPP >template. William, how much "process modeling" do you want to describe our >section of the paper (#3 "Elements of CPP")? Dave Minch has outlined the >"actors" and "actions" involved with the provider processes of >"Registration", "Benefit Verification", "Claim Submission", and >"Collection". Many of these processes require the provider to have >information in our CPP record. Do you want our paper to model/describe the >parts of these processes that are directly related to the CPP information? > >Comments appreciated. >-Chris > >At 08:30 AM 5/2/02 -0500, Dick Brooks wrote: > >Dale, > > > >Regarding: > > >However, to complete this exercise, I will need >some information. If > > you need to make extensions > > >to what is in the 2.0 CPPA schema, I will need to > > >know what these are. I think packaging of EDI in > > >the manner of EDIINT AS2 was what Dick > > >mentioned, but with a standard > > >ebXML header. Anyway, I will need an overview of > > >the required functionality, and sample BPSS > > >instances. > > > >The HIPAA implementation guides do not define a method for data exchange. > >There is a project under the WEDi/AFEHCT umbrella to identify a transport > >mechanism. In the mean time I propose that we use the following Business > >Process outline of a file transfer protocol modeled after the way current > >clearinghouses operate, to create a straw man CPA template: > > > >SIMPLE FILE TRANSFER BUSINESS PROCESS > > > >Operation 1: > > > >Send a HIPAA complaint X12 transaction to a Trading Partner > > > >Protocol: > > > >Sender sends a message with Service/Action containing Upload/Request with > >the X12 transaction in the payload of the message > > > >Receiver responds with Upload/Response containing an Acknowledgement > >indicating successful receipt of the data or an error element indicating > >rejection of the data. > > > >Operation 2: > > > >Retrieve HIPAA compliant data from a "mailbox" residing on a Trading > >Partners System or within a 3rd Party "Clearinghouse" system. > > > >Protocol: > > > >Requester sends a message to the system hosting their "mailbox" with a > >Service/Action containing Directory/Request along with search criteria > >contained in the message payload (encoded in XML?). > > > >Server responds with a Service/Action containing Directory/Response which > >contains a payload (encoded in XML?) listing all the X12 documents in > >the requesters "mailbox" waiting to be retrieved. > > > >Requester loops through the directory listing and sends a Service/Action > >of Download/Request for each file to retrieve. > > > >Server responds to Download/Request with a Download/Response that contains > >the X12 data requested. > > > >After saving the X12 data contained in the Download/Response the requester > >sends a DownloadComplete/Request to the server indicating that the data > >was received/accepted. > > > >The server responds to the DownloadComplete/Request with a > >DownloadComplete/Response after the X12 data has been removed from the > >requesters mailbox. The file is considered delivered at this point. > > > >General Provisions of the above Business Process: > > > >1.A username/password is needed to send/receive data > >2. All interactions occur over SSL/HTTP to protect username/passwords > >3. All message exchanges are "onceandonlyonce" delivery semantics > >4. Payload data (X12 transactions) will be encrypted/signed using either > >OpenPGP or S/MIME version 3 standards > > > > > >I know this is an incomplete business process, but I hope it is sufficient > >to begin formulating a CPA template. We can adjust the template later to > >match the specs that come out of the WEDi/AFEHCT project. > > > >Regards, > > > > > >Dick Brooks > >Systrends, Inc > >7855 South River Parkway, Suite 111 > >Tempe, Arizona 85284 > >Web: www.systrends.com ><<http://www.systrends.com/>http://www.systrends.com> > >Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 > > > >-----Original Message----- > >From: Dale Moberg [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, May 01, 2002 9:32 AM > >To: Brooks, Dick; Christopher J. Feahr, OD; Marcallee Jackson; Dick > >Brooks; Dave Minch > >Cc: William J. Kammerer; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > >[EMAIL PROTECTED] > >Subject: RE: our section of the paper > > > >I noticed below that Dick has signed me on > >to do a sample CPA template for review > >by WEDI analysts. > >A CPA template is a CPA filled out for one side, > >with certain blanks left for the other side to fill in. > > > >Unlike CPPs, CPA templates are best suited for > >a take-it-or-leave-it approach to setting up > >the mechanics of a collaboration. A fixed BPSS, > >fixed transports, fixed security, and so on. > > > >However, unlike CPPs, the potential complexity > >of both CPA formation from CPPs as well as the complexity of > >the not-yet-finished negotiation protocol can be avoided. > >Much better for the short term, IMO. > > > >Actually, templates were an early idea, unfortunately > >left out of the 1.0 specification. Definitely included > >in the Oasis initial public review specification released > >last week. > > > >However, to complete this exercise, I will need some > >information. If you need to make extensions to what > >is in the 2.0 CPPA schema, I will need to know what these > >are. I think packaging of EDI in the manner of > >EDIINT AS2 was what Dick mentioned, but with a standard > >ebXML header. Anyway, I will need an overview of > >the required functionality, and sample BPSS instances. > > > >Thanks, > >Dale Moberg > > > >-----Original Message----- > >From: Dick Brooks [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, May 01, 2002 6:06 AM > >To: Christopher J. Feahr, OD; Marcallee Jackson; Dick Brooks; Dave Minch > >Cc: William J. Kammerer; [EMAIL PROTECTED]; > >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Dale Moberg > >Subject: RE: our section of the paper > > > >Chris, > > > >Sorry for the long delay, I've been attending business meetings in > >Europe > >and have had little to no e-mail access. > > > >In a previous post I mentioned a meeting between myself and Dale Moberg, > >chair of the OASIS CPP/CPA technical committee, where we discussed the > >specific needs of HIPAA implementers. Dale suggested that a relatively > >new > >capability of the CPP/CPA specs, called CPA Templates, could provide a > >solution. > > > >During this meeting Dale and I agreed to produce a straw man CPA > >template > >and a description of it's elements, that would could potentially be used > >by > >two HIPAA trading partners to perform a simple transfer of X12 > >documents, > >using ebXML's message service. We have committed to providing a draft of > >this document to this group by May 18th. > > > >Again, I apologize for the long delay in responding. My travel schedule > >appears to be slowing and I hope to have time to focus on this work over > >the > >next two weeks. > > > >Regards, > > > >Dick Brooks > >Systrends, Inc > >7855 South River Parkway, Suite 111 > >Tempe, Arizona 85284 > >Web: www.systrends.com <<http://www.systrends.com>http://www.systrends.com> > >Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 > >-----Original Message----- > >From: Christopher J. Feahr, OD > >[<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] > >Sent: Friday, April 19, 2002 8:05 PM > >To: Marcallee Jackson; Dick Brooks; Dave Minch > >Cc: William J. Kammerer; [EMAIL PROTECTED]; > >[EMAIL PROTECTED]; [EMAIL PROTECTED] > >Subject: our section of the paper > > > >Dave,Dick,and Marcallee, > >Shall we take a stab at our section of the white paper: the definition > >of > >the data elements of the WEDI-SNIP CPP? I just finished looking at the > >prototype ebXML registry that Rachel posted recently. The main link, > >again, is: > ><http://ebxmlrr.sourceforge.net/registryBrowserGuide/registryBrowserGuide>h >ttp://ebxmlrr.sourceforge.net/registryBrowserGuide/registryBrowserGuide > > > >.htm > >l > > > >First, you install the Java run-time module called "WebStart" (which > >comes > >preconfigured to connect to a couple sample applications like Corel > >Draw). After WebStart is installed, you simply visit the following link > >with MSIE to start the registry browser: > ><http://ebxmlrr.sourceforge.net/registryBrowser/registryBrowser.jnlp>http:/ >/ebxmlrr.sourceforge.net/registryBrowser/registryBrowser.jnlp > > > > > >Your WebStart module fires up and loads the registry browser application > >(GUI). From the reg-browser's pick-list (has only one item at the > >moment) > >you select this demonstration CPP registry in Hong Kong and you have > >several ways to search it. Searching by "organization" brings up the > >two > >companies listed (Sun and one other company) and then you can drill into > >each company's profile and see company identifiers, address info, > >contacts, > >phone numbers, etc. In the "ad hoc query" mode, you can search the > >registry with SQL statements. very cool! > > > >I can't imagine why we would not want to recommend the full-blown, ebXML > >spec. for the structure of the CPP registry. Would the requirements for > >a > >WS-CPP browser application be outside the scope of this group, or would > >we > >want to list some general requirements and recommendations for any > >company > >who wanted to create one of these applications as a front end for their > >own > >registry? It seems that a hosting entity could offer CEs free or > >low-cost > >GUI access to a printable listing of any single company's profile > >data. Eventually, CEs who access this frequently could wire up direct > >XML > >connectivity. > > > >Should we be coordinating the development of our basic WS-CPP registry > >schema with the UBL Liaison Subcommittee in OASIS? > > > >...do we jump right into the enumeration of the data elements now? > > > >-Chris > > > > > > > > > > > >Christopher J. Feahr, OD > ><http://visiondatastandard.org>http://visiondatastandard.org > >[EMAIL PROTECTED] > >Cell/Pager: 707-529-2268 > > >Christopher J. Feahr, OD >http://visiondatastandard.org >[EMAIL PROTECTED] >Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
