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
