NCPDP has created a task group to assist in the routing registry endeavor. As the task group is made up of business and technical folks in the pharmacy industry, is there a primer document or something they can read to come up to speed with the work being done? thank you
-----Original Message----- From: Dave Minch [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:34 PM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject: RE: registry and repository Chris, It looks good - just a couple of additional thoughts on the repository: 3. There is only one copy... -- this probably isn't needed as a statement in the requirements, because it would tend to limit one's flexibility to post a primary & alternate address (which can be provided for in the registry), or for a Plan to contract with a CH to use their repository to post a second copy. From a conceptual point of view, of course, you are correct that the CPP itself isn't distributed across several repositories. 2. The repository remains under the direct control of the trading partner to whom it refers ("the owner"). This statement would also tend to exclude Business Associate relationships -- e.g. where an entity wants to contract with a third party to use their services which may include posting a CPP for them. I would add the term "or their contracted agent" at the end of the sentence just to keep that door open. Hope to hear other feedback on the concept since it will form the base of where we go from here. BTW, I need to get some terms defined for the business requirements workflow -- needed to create the business processes use cases which are then used in classification of the CPP data sets. As I recall, there were some defined terms put out a few months back, but I can't find them now. Anyone know who developed them and where they are? Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 5: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
