The CPP spec does allow for versioning. I've used the trading partner profile from our Sybase "paperfree" application as a model for TP information, and have added several elements beyond that. Rachel is correct in that most EDI translators appear to have a more or less sophisticated trading partner profile management function. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
-----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 6:52 PM To: [EMAIL PROTECTED] Subject: RE: registry and repository- version control Chris, What you're referring to is the trading partner profile management function that most good commercial EDI management systems provide. Some provide more or less functionality than others. If I'm not mistaken, I believe that the CPP spec allows for versioning???? Rachel -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 1:30 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: registry and repository- version control Rachel, I agree that it would not seem to be necessary to check the repository info. very often. I was thinking, however, of including a "version indicator" field somewhere (maybe just Active/Inactive flag, version date, etc.) in the repository and possibly retaining several "expired" repository versions in case the owner needed to roll back to or look at one of them. But if the receiver wasn't yelling at the sender about something going to the wrong portal and/or transactions were not being rejected, then would there even be a reason for a sender to recheck this? The other thing that occurred to me (I have approx. zero operational experience with EDI.. so please bear with me!) is that commercial translator systems must have some sort of configuration template/database into which the prospective user will have to key all/most of this repository data... sort of his local "EDI Address Book". Should we be talking to translator vendors about how this info is managed locally by the interchange senders? The obvious advantage of aligning our repository structure with a standard local user's "address book" would be auto-updating ability. -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
