Issues for Patient Identification Service (PIDS) RTF3 Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1245: Value Sets for Coded data elements in the PID segment
Issue 1416: Update Appendix 8
Issue 1417: Update PIDS spec to use Notification Service event type language
Issue 1533: PIDS opening paragraph for IdentifyPerson
Issue 1820: Implementation problems of IDL for SequentialAccess interface
Issue 1821: "Not implemented" exception
Issue 1822: Exception that indicates that server is missing is needed
Issue 1823: Additional method in ProfileAccess and IdentifyPerson needed
Issue 1824: processing for register_ids, register_new_ids, register_these_ids
Issue 1825: Exception missing
Issue 1827: HNE does not have a list of required person traits for a person addition
Issue 1828: update_and_clear_traits method of ProfileAccess interface
Issue 1830: Allow a way to determine originating domain
Issue 1831: update_and_clear_traits method issue
Issue 1832: merge_ids method
Issue 1833: load_profiles method issue
Issue 1834: get_corresponding_ids method issue
Issue 1835: Change description of ExternalIds trait
Issue 1836: Add find_or_register operation to CorrelationMgr interface
Issue 1838: Typos in PIDS document
Issue 1839: include statement in PersonldService not valid
Issue 1840: Attribute to be removed from PersonldService module
Issue 1841: Description of the InvalidId exception
Issue 2093: The spec is not clear enough on How to Handle Links
Issue 2670: The supported_traits operation returns trait names but not types
Issue 2671: "Relationship to PMF"
Issue 2672: Explicit "Link and Unlink Operations needed?
Issue 2737: Typos in formal/99-03-05
Issue 2738: semantics of aliases in context of correlation manager
Issue 2739:
Issue 2741:
Issue 2742:
Issue 2744: Extended Cleanup of Description of QoS Properties
Issue 2745:
Issue 2746:
Issue 2747:
Issue 2748:
Issue 2749:
Issue 2750:
Issue 2752:
Issue 2835: need find_candidates operation on CorrelationMgr
Issue 2836: need to be able to get description of matching algorithm
Issue 2870: Issue:: CorrelationMgr Interface (typo)
Issue 2871: IDL error (typo)
Issue 2872: Need another type for this trait in PersonIdTraits module
Issue 2937: CASE troubles
Issue 2938: how to report database-or-infrastructure-level erros as exceptions
Issue 2965: Question or issue regarding collaboration diagrams
Issue 3017: should we reference the recent HL7 SIGMPI harmonization with PIDS
Issue 3019: using XML for traits and metadata
Issue 3067: Relationship to PMF
Issue 3789: "RequiredTraits" exception issue
Issue 3859: The IDL contained in the PIDS specification is not CORBA compliant
Issue 5537: The IDL for SpecifiedTraits seems incorrect

Issue 1245: Value Sets for Coded data elements in the PID segment (pids-rtf2)

Summary:  PIDS specification has recommended the HL7 PID segment for standard trait names. The data type for many of the traits in the PID segment (like race, martial status etc.) are CE (Coded). An important aspect of achieving interoperatibility is to make a tight connection between coded fields and the coded vocabulary items that are possible values of the field. For example, the field "Sex" might have the allowable set of values: male, female and ambagious. To achieve that goal HL7 has defined  value sets for the various coded fields. In most cases the values sets are from existing standard vocabulary  like LOINC, UMLS etc. I was wondering  - it will be nice if PIDS specifications also recommended the values sets for the coded fields in the PID segment to be the same as recommended by the HL7 standards.
 
 

 received issue

Summary: The "8. Appendix - Use Cases" in the PIDS spec do not accurately reflect
 how PIDS is to be used.  This should be updated.
 

 received issue

Summary: The "10. Appendix - Event Descriptions" in the PIDS spec were done
 before the Notification Service was adopted.  The Notification Service
 uses a different mechanism to specify event types.  The PIDS spec should
 be updated to use the Notification Service event type language.
 

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

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
 

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

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.

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.

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.

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.

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

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.
 
 

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.

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.

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.

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

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?

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

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.

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.

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

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.

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

Summary: The spec is not clear enough  on How to Handle Links
 
 Based on clear feedback in HL7 forums, I know  there is serious concern
 over the fact that our Interfaces and info model  show explicit support
 for merges (merges deactivate one dupe and leave  another intact) but
 only implicit support for links (links leave multiple  intact;  In
 effect, they simply assert or "record"  dupes).
 
 I find the last paragraph of  2.7 confusing:  If PIDS implementations are
 to be able to "carry  administrative and auditing attributes such as
 timestamp, user stamp, source  system, and specific operation types",
 then it raises thevalid question:  how does the implementation know when
 a link operation has occurred?  We  do not tell them anywhere in the spec
 as it stands.  
 

Summary: Issue: "Client needs trait-type awareness so it can type-validate
 interactive trait entries"
 
 The supported_traits operation returns trait names but not types, leaving
 the client unable to proactively validate trait entry.  While the current
 spec provides for the server
 to throw InvalidTraitFormat on a bad date,  It would be better to allow
 the client to know a priori that the Birth Date is a date so that it can,
 for example put up a visual date picker or otherwise validate the date
 before the
 user has tabbed on to other fields.
 

Summary: Issue: "Relationship to PMF"
 What is the complete and useful normative relationship of PIDS to the Party
 Mangement Facility (PMF)?  On my first reading of it, I believe the PMF spec
 has already addressed part of it by relating their QualifiedID to the PIDS
 QualifiedPersonID (both are an identifier value qualified by its Domain Id).
 I would add that the Property Lists by which the PMF records attribution of
 a party can be mapped to PIDS traits, although I wonder if we could be even
 more specific like "Trait Names that match property names (if they are
 Namespace-qualified) are understood to correspond.  If this is agreed, then
 we have a formalized linkage of not only the IDs but the Traits, and the
 basis for integration between the two without coupling..
 

Summary: Issue: Does the spec need explicit "Link and Unlink Operations, or just
 guidance on how to assert the
 DuplicateIDs and ExternalIDs traits?
 

Summary: ISSUE Typos:  Document formal/99-03-05 still has a number of typos that 
 were to be fixed in the first RTF.
 This includes PHONE_NUMER_HOME instead of PHONE_NUMBER_HOME in the 
 HL7Version2_3.idl and
 #pragma prefix "org/omg" on pages 2-13 and 2-44.
 

Summary: I think the spec needs some narrative on the semantics of aliases.
 Specifically, it fails to point out that the receipt of an alias from a
 source domian does not necessarily imply that its value is to be used as an
 alias in the correlating domain.
 
 This clarification is important because if a VIP (say, the president) is
 anonymous under an alias in a source domain it might be entirely appropriate
 to treat that alais as a real name in the correlating domain.  Similarly,
 the correlating domain should be free to maintain its own alias for persons
 independent of source domains.
 

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.

Issue 1) above overlaps with issue 2740, so will not be 

             considered here. Regarding issue 2), I personally disagree

             with this. I think it's conceivable to set a StartTime or

             StopTime on a ProxyConsumer or a ProxySupplier. When set on

             a ProxyConsumer, it informs that Proxy upon receiving an 

             event with a StartTime or StopTime in its header, it should

             honor that setting. In the case of StartTime, it should not

             queue the event for delivery to ProxySuppliers until StartTime

             has occurred. In the case of StopTime, if the time the event

             is received is later than StopTime, it should simply discard

             the event. In general, I think we should not preclude the

             setting of QoS properties on specific objects unless there is

             clearly no possible semantic that can be associated with them.

             Specific implementations are always free (and still in 

             compliance) to disallow setting of QoS properties on specific

             objects if they choose, but the spec itself should not preclude

             implementors from supporting the setting of a QoS property on 

             specific objects unless that setting very clearly could have

             no meaning. My opinion is that the author of this issue is

             overly concerned that the specification describe the exact

             behavior of their specific information, which I feel is 

             unnecessary in any case (the specification certainly does not

             describe every aspect of the behavior of our implementation!).

             Issue 3) I could go along with, as I cannot think of any

             reasonable meaning that could be associated with OrderPolicy

             on the Consumer side of the channel. I agree that OrderPolicy

             and DiscardPolicy have similar semantics here, and what's 

             already stated in the spec with respect to DiscardPolicy should

             apply to OrderPolicy too. Regarding issue 4), I agree however

             personally feel this is so obvious it doesn't need to be stated.

             Finally, regarding the basic recommendation that table 2-4

             be made more granular (to show applicability of QoS properties

             to specific styles of Proxies), I have no real opposition to 

             doing this, except that it may make it difficult to fit the

             table on the page.



VOTE: Again, I will break down this vote into the following subvotes. Note

      that I consider issue 1) to be covered by issue 2740, so we'll ignore

      that one here.



        Issue 2744c: YES means to state the MaximumBatchSize and

                     PacingInterval do not apply to anything other than

                     Sequence Proxies (and the Channel and Admins that

                     create them). NO means to do nothing.



        Issue 2744d: YES means to break Table 2-4 down into further 

                     columns that show applicability of QoS properties to

                     each specific style of Proxy. NO means to do nothing.


NOTE: 2744c and 2744d passed

Summary: We need a version of find_candiate that returns candidates (each with
 qualified id and profile) from multiple domains - not just the correlating
 domain.
 

Summary: In order for a client to rightly interpret the results of a search using
 find_candidates or find_or_register_ids, it would be very helpful to have an
 operation to get a description of the matching algorithm employed
 

Summary: The text of the spec for CorrelationMgr has find_or_register_ids() in it 
 but it isn"t in the IDL (section 2.6.7) on page 2-41, although it is in the 
 overall IDL. at the end of the document.
 

Summary: There is an extra "};" in the PersonIdService.idl file just before the
 added find_or_register_ids method in the CorrelationMgr interface

Summary: I have one request for the revision task force. There is
  a trait in the PersonIdTraits module - PIDS/ExternalIds and its type is
  QualifiedPersonIdSeq. We need another type for this trait - which will
  correspond to the HL7 type for the patient"s Identifiers, e.g. it should
  have the domain, identifier and the type of identifier. A system can
  support multiple alternate patient identifiers - so in order to fully
  qualify what kind of externalId is being used, its type ( HL7 suggested
  table of Identifiers types can be used) needs to be defined.
 

Since with CORBA 2.3, everything is to be case insensitive there are some 
problems
with the PersonIdService.idl.   The statement defining: "Trait trait" in 
TraitSelector now is illegal. This requires
a minor change in the IDL to make the instance of Trait to be different.

Is there an exception, or a "correct way"  to let the client know that an
underlying infrastructure error (like an RDBMS error) has occurred?

> I think that this example on page 3-127 is wrong or terribly misleading.  
>           [x < 0] 4: invert (x, color)    -- conditional Message
> 
> If I read right, condition-clause is supposed to follow the sequence number. 
> So the correct example would be: 
>           4 [x < 0] : invert (x, color)    -- conditional Message. 
> 
> To me, this is a guarded message
>           [x < 0] 4: invert (x, color)    -- guarded Message

We in SIGMPI have recently made some good strides in harmonizing HL7 and
PIDS by adding some missing events and updating the identifier management
language (id domains, profiles, traits).  We are even applying event names
that approximate the PIDS operation names where applicable in the new
events:

get person demographics
find candidates
get corresponding identifiers
allocate identifiers (Tim notes you can do that with a register_new_ids
supplying an empty profile, although personally I am disgusted by such a
practice because it commonly leads to dupes, and is only valid for
intentionally-to-be-reused IDs which is also philosophically questionable)

Since this representation of trait values in XML is fully-compliant at the
IDL level, it's not a functionality change.
The expression of trait metadata (so as to document the STRUCTURE of it) is
a functionality change but it is defensible as a fix, even to make to make
it possible for PIDS clients to validate dates - not just textual format but
the value domains at the basic and abstract datatypes.

I think we can all agree at this point that we need an operation on
IdentificationComponent called

        get_trait_metatdata

and I feel strongly that it should use DTD notation.  If we agree at this
level (please everyone - do you agree so far?), then I think the next
question is how to express basic and abstract types in the DTD.

Is there, or can there be made, a formal relationship between PMF properties
and PIDS traits?
Partial Proposed Resolution:
The PMF uses CosPropertyService interfaces for property manipulation. These
properties are not explicitly namespace-qualified.

typedef string PropertyName;
struct Property {
PropertyName property_name;
any property_value;
};

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.

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.

Resolution:
Prefix each of the offending types with the qualifier "PersonIdService::"
as follows:
         struct TraitSelector {
                 PersonIdService::Trait trait;

The IDL for SpecifiedTraits seems incorrect. There is not definition for elements of this union for ALL_TRAITS and NO_TRAITS so these values can not be used.