Dave,
I agree completely with these two suggestions. I was trying so hard to
make a conceptual point about what should be possible that I inadvertently
implied that these arrangements were "requirements".
Thanks,
Chris
At 12:33 PM 6/6/02 -0700, Dave Minch wrote:
>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
Christopher J. Feahr, OD
http://visiondatastandard.org
[EMAIL PROTECTED]
Cell/Pager: 707-529-2268
