A repository for a CPP is what an ebXML registry/repository stores...as well as other information. OASIS has an ebXML registry/repository.
Rachel -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 1:09 PM To: [EMAIL PROTECTED] Subject: RE: registry and repository Rachel, Thanks for your comments. I did not realize that we had OASIS folks following this discussion... that's great! Just as a "reality check", I did fwd. a copy of my last post to Jon Bosak for comment. Lisa indicated that her committee was focused on the registry component. I believe Dave Minch is inquiring about standard structures or templates that might be evolving in OASIS for all or part of the CPP-repository. Are you aware of anything like this, Rachel? Regards, Chris At 10:24 PM 6/4/02 -0500, Rachel Foerster wrote: >Chris, > >My immediate first-read impression is that this is a good approach. I would >also add an additional concept/idea that surfaced this week during >discussions at X12 in Minneapolis, i.e., that for most/many trading partners >accessing such a registry/repository doesn't necessarily have to be a >dynamic task performed each time an interchange is created. Rather, it might >be necessary to access such a registry/repository once or intermittently in >order to obtain the needed information for addressing/routing. Of course, >this assumes that the addressing/routing information is more static than >volatile. But, my gut tells me that it will be more static rather than >volatile....at least during the early months/years of HIPAA EDI deployment. > >Furthermore, keep in mind that OASIS has an ebXML compliant >registry/repository already developed. It would be worthwhile to investigate >how healthcare could tap into using it. > >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 > > >-----Original Message----- >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, June 04, 2002 7:18 PM >To: [EMAIL PROTECTED] >Subject: registry and repository > > >Dear Group: >Dave Minch has been researching these terms as they are used in the ebXML >world and we have been talking offline about their applicability to this >project. Please correct me if you feel that any of this is off-base, but I >would like to propose these two basic concepts for our project. > >REPOSITORY: >The repository is the actual record of connectivity requirements and other >information that is needed to set up a trading relationship. Some of our >repository elements may be unique to healthcare or refer to a unique >requirement of HIPAA, but most will be data elements commonly required by >any 2 entities wishing to establish electronic data exchange. > >The key points about the repository: >1. It is essentially one collection of data about one trading partner's >requirements, although it may be compartmentalized and it may be spread >over several linked "documents" or URLs >2. The repository remains under the direct control of the trading partner >to whom it refers (the "owner") >3. There is only one copy of the repository in existence >4. Each TP can decide what parts of his/her repository are exposed to whom >5. The repository can have any physical or logical location that is >acceptable to the owner > >REGISTRY: >The registry is a separate database, built to standard specifications, and >able to be accessed with a standard query protocol. It's purpose is to >link the all the possible identifiers used by a single trading partner with >his/her SINGLE repository ADDRESS (generally, a URL). For example, if >Company A is known by 10 nationally unique alphanumeric codes or names, >then he would probably want to have 10 different registry records, in which >each ID code points to the same repository, containing all of his "TPA" >information. > >Key points about the registry: >1. The registry should conform strictly to an established standard (like >ebXML) so that it can be queried automatically using standard protocols. >2. An industry like healthcare can support any number of registries. There >might be a slight advantage in having only one registry for healthcare, but >it would be almost the same effort to have a system query 3 or 4 or even 20 >registries in rapid succession. All we would be looking for in the >registry is the URL for the company's SINGLE repository record or >record-collection. >3. There is no limit to the number of different identifiers that can be >linked in a registry to a single CPP repository. This means that in >addition to the identifiers permitted in the ISA, we could list a company's >common names and abbreviations (e.g., "Vision Service Plan" or "VSP"), any >of the company's National PlanIDs, etc. Some standardization here would be >helpful and in general, we would expect the identifiers printed on the >subscriber ID card to be the same ones placed in the registry. There is no >requirement, however, to restrict the registry pointer IDs to the set of ID >codes that are "legal" in the ISA. ISA receiver ID preferences would be >spelled out in the CPP repository. >4. A company would be free to list itself in as many registries as it >liked. Companies should list the same identifiers in every registry, but >the system would still function OK if the different registries were not >perfectly synchronized... as long as the repository URL was listed >correctly in each record. >5. The registry would be a relatively static, low maintenance database. As >long as the listed entity kept the URL of its CPP Repository constant, >there would be no need to edit the pointers in the registry. The contents >and even the physical location of the repository could be changed whenever >necessary (by the owner), but it would only rarely be necessary to edit the >registry. > >If this general approach to storing and indexing the CPP information is >acceptable, then I would like to suggest that we discuss the particulars of >the CPP registry with the OASIS folks and that we use Dave's suggested, >2-part approach to defining the contents of the repository. Part 1 would >be a listing of all the pure data elements of the CPP (using XML >terminology), separate from any external hierarchies. Then Part 2 would be >a specific implementation model (along the lines of the one I have posted) >optimized for small providers who wish to connect directly to payors and >for those payors to easily determine a "return path" back to the >provider. The CH/VAN community may have a slightly different set of needs >and may wish to create a different repository structure (using the same >universe of CPP data elements), but I suggest that would be out of scope >for this project. > >How does this sound so far? > >Regards, >Chris > > >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
