Person Identification Service Avatar
  1. OMG Specification

Person Identification Service — Closed Issues

  • Acronym: PIDS
  • Issues Count: 24
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
PIDS11-34 The IDL contained in the PIDS specification is not CORBA compliant PIDS 1.0 PIDS 1.1 Resolved closed
PIDS11-32 $issue.summary PIDS 1.0 PIDS 1.1 Resolved closed
PIDS11-31 Extended Cleanup of Description of QoS Properties PIDS 1.0 PIDS 1.1 Resolved closed
PIDS11-33 "RequiredTraits" exception issue PIDS 1.0 PIDS 1.1 Resolved closed
PIDS-16 Add find_or_register operation to CorrelationMgr interface PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-18 include statement in PersonldService not valid PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-17 Typos in PIDS document PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-20 Description of the InvalidId exception PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-19 Attribute to be removed from PersonldService module PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-15 Change description of ExternalIds trait PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-14 get_corresponding_ids method issue PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-13 load_profiles method issue PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-12 merge_ids method PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-11 update_and_clear_traits method issue PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-10 Allow a way to determine originating domain PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-9 update_and_clear_traits method of ProfileAccess interface PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-8 HNE does not have a list of required person traits for a person addition PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-6 processing for register_ids, register_new_ids, register_these_ids PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-5 Additional method in ProfileAccess and IdentifyPerson needed PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-4 Exception that indicates that server is missing is needed PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-7 Exception missing PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-3 "Not implemented" exception PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-1 PIDS opening paragraph for IdentifyPerson PIDS 1.0b1 PIDS 1.0 Resolved closed
PIDS-2 Implementation problems of IDL for SequentialAccess interface PIDS 1.0b1 PIDS 1.0 Resolved closed

Issues Descriptions

The IDL contained in the PIDS specification is not CORBA compliant

  • Key: PIDS11-34
  • Legacy Issue Number: 3859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The IDL contained in the PIDS specification is not CORBA compliant.

    Specifically, the declarations

    struct TaggedProfile

    { PersonId id; Profile profile; }

    ;

    and

    struct TraitSelector

    { Trait trait; float weight; }

    ;

    fail to comply with the rule that the semantics of OMG IDL forbids identifiers in the same scope to differ only in case.

    The PIDS IDL will compile under the OrbixWeb ORB, but it fails to compile under ORBacus unless the --case-sensitive option (which is not CORBA compliant) is used.

  • Reported: PIDS 1.0 — Fri, 15 Sep 2000 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT

${issue.summary}

  • Key: PIDS11-32
  • Legacy Issue Number: 2750
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: PIDS 1.0 — Thu, 17 Jun 1999 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    closed

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Extended Cleanup of Description of QoS Properties

  • Key: PIDS11-31
  • Legacy Issue Number: 2744
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author enumerates several points of confusion with

    regard to the applicability of QoS properties to specific objects

    within a channel. The issues are as follows:

    1) Setting Priority or Timeout on a ConsumerAdmin or ProxySupplier

    is meaningless, and should be disallowed

    2) StartTimeSupport and StopTimeSupported on a ProxyConsumer or

    SupplierAdmin is meaningless, and should be disallowed

    3) OrderPolicy (like DiscardPolicy) on a ProxyConsumer or

    SupplierAdmin is meaningless, and should be disallowed

    4) MaximumBatchSize and PacingInterval are meaningless for Any

    and Structured Event style Proxies

    The issue author goes onto suggest that Table 2-4 should add

    specific columns for each style of Proxy, so that the applicability

    of QoS properties to specific objects can be designated with finer

    granularity.

  • Reported: PIDS 1.0 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    fixed, see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT

"RequiredTraits" exception issue

  • Key: PIDS11-33
  • Legacy Issue Number: 3789
  • Status: closed  
  • Source: Level Seven Visualizations ( Jon Farmer)
  • Summary:

    he "RequiredTraits" exception returns a sequence of traits. But
    make_ids_permenant takes an ARRAY
    of input ids. So this exception if thrown won't provide any usefull
    information as to which id
    had the problem.

    Our implementation, rather than throwing the exception, just creates the ID
    in a temporary state. However, as we recently considered supporting the
    exception in conjunction with a probabilistic matching algorithm, we found
    the following ambiguity:

    The RequiredTraits exception inlcudes a list of required traits, but the
    spec doesn't clarify that this is the complete list of required traits -
    assuming that its the same set for any input profile - so that the client
    can figure out which IDs need for traits.

    The problem with that semantic is as follows. Some probabilisitc matching
    algorithms can only determine the adequacy of the incoming trait set by
    inspecting the VALUES of the trait types supplied. for example, if the
    incoming request tries to register two ids, one with first=John ,
    Last=Smith, and the second with First=Mergetroid Last=Pepperdyne, a
    probabilisitc algorithm will likely accept the second but reject the first;
    YET BOTH supplied the same traits. Hwo could the client figure out what's
    missing? How the server even figure out what's missing? Neither can. ONLY
    THE ALGORITHM KNOWS....... AND IT ONLY KNOWS ONCE IT HAS SEEN THE INPUTS.

    Therefore we need to define clearly what the exception semantics are, and in
    a way that doesn't preclude the use of probabilistic matchers that cannot
    assess adequacy in a "one trait list fits all" manner.

    One possible solution is to have the exception return a SEQUENCE OF
    offending ids - so the client can know which are offensive. Instead of also
    including for each the set of traits needed, the return structure could show
    the confidence deficit for each.

  • Reported: PIDS 1.0 — Thu, 10 Aug 2000 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Add find_or_register operation to CorrelationMgr interface

  • Key: PIDS-16
  • Legacy Issue Number: 1836
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    Update spec as below.

  • Updated: Fri, 6 Mar 2015 20:50 GMT

include statement in PersonldService not valid

  • Key: PIDS-18
  • Legacy Issue Number: 1839
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: PIDS 1.0b1 — Wed, 19 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Typos in PIDS document

  • Key: PIDS-17
  • Legacy Issue Number: 1838
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Wed, 19 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Description of the InvalidId exception

  • Key: PIDS-20
  • Legacy Issue Number: 1841
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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."

  • Reported: PIDS 1.0b1 — Wed, 19 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    resplved

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Attribute to be removed from PersonldService module

  • Key: PIDS-19
  • Legacy Issue Number: 1840
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Wed, 19 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    closed

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Change description of ExternalIds trait

  • Key: PIDS-15
  • Legacy Issue Number: 1835
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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."

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    resolved is 1836, close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

get_corresponding_ids method issue

  • Key: PIDS-14
  • Legacy Issue Number: 1834
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    issue closed, no action

  • Updated: Fri, 6 Mar 2015 20:50 GMT

load_profiles method issue

  • Key: PIDS-13
  • Legacy Issue Number: 1833
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    Update spec as described below.

  • Updated: Fri, 6 Mar 2015 20:50 GMT

merge_ids method

  • Key: PIDS-12
  • Legacy Issue Number: 1832
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    Add new exception as described below.

  • Updated: Fri, 6 Mar 2015 20:50 GMT

update_and_clear_traits method issue

  • Key: PIDS-11
  • Legacy Issue Number: 1831
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    no action taken, close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Allow a way to determine originating domain

  • Key: PIDS-10
  • Legacy Issue Number: 1830
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    no action taken, close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

update_and_clear_traits method of ProfileAccess interface

  • Key: PIDS-9
  • Legacy Issue Number: 1828
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

HNE does not have a list of required person traits for a person addition

  • Key: PIDS-8
  • Legacy Issue Number: 1827
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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".

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:50 GMT

processing for register_ids, register_new_ids, register_these_ids

  • Key: PIDS-6
  • Legacy Issue Number: 1824
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    Update the spec as below.

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Additional method in ProfileAccess and IdentifyPerson needed

  • Key: PIDS-5
  • Legacy Issue Number: 1823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Exception that indicates that server is missing is needed

  • Key: PIDS-4
  • Legacy Issue Number: 1822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    close issue, see above

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Exception missing

  • Key: PIDS-7
  • Legacy Issue Number: 1825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    no action taken, closed issue

  • Updated: Fri, 6 Mar 2015 20:50 GMT

"Not implemented" exception

  • Key: PIDS-3
  • Legacy Issue Number: 1821
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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()

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:50 GMT

PIDS opening paragraph for IdentifyPerson

  • Key: PIDS-1
  • Legacy Issue Number: 1533
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: PIDS 1.0b1 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    Drop - unless further explanation can be provided.

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Implementation problems of IDL for SequentialAccess interface

  • Key: PIDS-2
  • Legacy Issue Number: 1820
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: PIDS 1.0b1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — PIDS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:50 GMT