Lisa, I'm at X12 in Minneapolis right now and I think you are too.
In any case, I'm all for a field trial.....is NIST and OASIS offering to help health care with this --- at no cost, of course! Rachel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 5:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: registry and repository Rachel and All, I've been tracking this list for some time and have had discussions with William Kammerer to do just this; that is, field a trial ebXML registry to hold appropriate CPPs. (William: please speak up if I mis-characterized our discussions.) To introduce myself, I'm on the OASIS/ebXML Registry Technical Committee. Given that the specs are relatively new, I have an interest in determining if the OASIS/ebXML Registry specs are really usuable by different industry segments. NIST would like to field a test registry for WEDI/SNIP CPPs. --lisa carnahan NIST (301)975-3362 [EMAIL PROTECTED] Quoting Rachel Foerster <[EMAIL PROTECTED]>: > 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 > >
