Summary: 2) Change PIDS interfaces a) Add a "find_or_register" operation to the CorrelationMgr interface that accepts a QualifiedTaggedProfileSeq instead of a TaggedProfileSeq like the IdMgr find_or_register operation. This would make the requirement for the QualifiedPersonId explicit. b) Add a new operation to the IdMgr interface called "add_external_ids". This would allow an explicit agreement and the part of the client and non-correlating service to track uncorrelated identifiers. A PIDS service could return NotImplemented if it doesn"t track external ids. A correlating PIDS service could also return NotImplemented if it doesn" t track non-correlated ids. I have attached the revised IDL for the IdMgr and CorrelationMgr interfaces. We like these changes because they make the requirement for the QualifiedPersonId explicit as well as removing the ambiguity associated with the ExternalIds trait. We appreciate all the thought that has gone into the PIDS specification and understand that our needs might be met in a more creative way that does not require any changes to the PIDS specification. We would appreciate any feedback you have.

Update spec as below.

Summary: The PersonIdService module has an include statement that is no longer
valid - "Notifications.idl".

resolved, close issue

Summary: There are a number of mostly minor typos in the final PIDS document I
obtained from the OMG web server.

I"ve annotated the corbamed/98-02-29.pdf file and placed it in
http://www.acl.lanl.gov/~dwf/PIDS/98-02-29.pdf. The changes are in
notes attached to the PDF document.

The most serious are two problems with the IDL. In the NamingAuthority
module: #pragma prefix "omg.org " should have the space removed after
org. In the HL7Version2_3 module, PHONE_NUMER_HOME should be replaced by
PHONE_NUMBER_HOME.

The others are mostly spelling corrections and name changes to match the
style guide used in the actual IDL.

resolved

Summary: The description of the InvalidId exception implies that PIDS servers
that only know about a subset of the IDs in an ID Domain would throw the
InvalidId exception when a client passes an unknown ID to a call. Many
of the operation calls take a sequence of IDs and the spec implies the
exception is thrown if any one of the passed in IDs are not known. This
is an over burden for a client to either know ahead of time which IDs
the server knows about or handle an exception to remove the violating
IDs and try again. In relation to the definition of the InvalidId
exception:

Please remove para 1 sentence 3.

PLease replace para 2 sentence 3 with "An Unkown ID passed into a call
only causes an exception to be raised if the operation signature only
takes one ID."

resplved

Summary: The PersonIdService module still contains the following:

readonly attribute Notification::EventComponent
event_component;

The Notification module was removed fro the adopted spec so this
attribute must also be removed.

closed

Summary: 1) Change description of ExternalIds trait to read "This read-only trait indicates the set of other IDs a person may have. The IDs listed may be from a different ID Domain than the ID Domain of the ID this trait is bound to. This is more general purpose than CorrelatedIds. The IDs listed in this trait may be set by other mechanisms than automatic correlation. For example, external ids are added to non-correlating domains using the IDMgr::add_external_ids operation. Correlating PIDS should return correlated ids. They should also return any non-correlated external ids if they are tracking non-correlated ids. Note that the client will not be able to tell the difference between correlated ids and non-correlated ids. Not all PIDS implementations will support this trait and the tracking of non-correlated ids." In the conformance section: "Tracking non-correlated external ids - If a PIDS service tracks non-correlated ids it must support the IdMgr::add_external_ids operation and the PIDS/ExternalIds trait."

resolved is 1836, close issue

Summary: 3. The "get_corresponding_ids" method of the IdMgr interface is intended to return a list of a person"s Ids that are associated with a given list of domains. A person can have different Id types associated with a given domain, such as the external patient Id, internal account number, external account number and patient internal number. How does the client software determine which Id is which?

issue closed, no action

Summary: 3. The "load_profiles" method of the CorrelationMgr interface should be revised to use exceptions that are consistent with the IdMgr interface.

Update spec as described below.

Summary: 2. The "merge_ids" method of the IdMgr interface should provide an exception that allows the server to notify the client when two valid enterprise Ids cannot be merged.

Add new exception as described below.

Summary: 2. The "update_and_clear_traits" method of the Identity interface should include the MultipleTraits exception as the "update_and_clear_traits" method in the ProfileAccess interface does.

no action taken, close issue

Summary: 3. Methods that update person traits or merge Enterprise Ids should allow for a way to determine the originating domain. For example, the "update_and_clear_traits" method of the ProfileAccess Interface does not have a parameter for the originating domain of the update.

no action taken, close issue

Summary: 3. In the "update_and_clear_traits"method of the ProfileAccess interface, the list of traits to clear and modify must be checked for invalid entries. The UknownTraits exception allows for only one list of trait names to be returned. This makes it impossible for the client to determine which list an invalid trait is in.

close issue

Summary: 3. HNE does not have a list of required person traits for a person addition. It requires that a certain number of primary, secondary, and/or tertiary person traits are defined. It tries to match the trait definitions to a "Use Case" and will not add a person unless the list of defined traits synchs up with at least one of the "Use Cases".

No Data Available

Summary: 3. The processing for the "register_ids", "register_new_ids" and "register_these_ids" is very similar. The implementation software will have to verify that each Id is not already in the system and return an enterprise Id for each person.

Update the spec as below.

Summary: A method is needed in the ProfileAccess and IdentifyPerson interfaces to indicate the maximum sequence size to be returned by the server. The method would allow clients to determine the appropriate size in advance, avoiding a server exception.

resolved, close issue

Summary: 2. An exception that indicates that the server is unavailable is needed. It would allow a client to inform a user of the reason that a person search cannot be completed. It is needed for several methods.

close issue, see above

Summary: 3. There is no exception to indicate if a person addition or update is unsuccessful. For example, if the IdMgr->register_new_ids method is called to add persons into HNE, there is no way to inform a client that the addition was unsuccessful.

no action taken, closed issue

Summary: 2. The "Not Implemented" exception is needed for the following interfaces and methods because HNE cannot support the functionality:

a) IdMgr->create_temporary_ids()
b) IdMgr->deactivate_ids()
c) IdMgr->make_ids_permanent()
d) IdMgr->unmerge_ids()

No Data Available

Summary: The first paragraph on identifyperson should state that it returns IDs given selection criteria traits.

Drop - unless further explanation can be provided.

Summary: In reviewing the documentation and IDL for the SequentialAccess Interface, I came to understand that there would be problems with its implementation.

The problems are:
a. Access Method
b. Performance
c. Memory Management

No Data Available