Issue 2872: Need another type for this trait in PersonIdTraits module (pids-rtf2) Source: (, ) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Revised Text: Actions taken: September 1, 1999: received issue Discussion: End of Annotations:===== ]From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: pids-rtf2%emerald%omg.org@mmm.com Message-ID: <862567DF.0051EA8A.00@em-stpmta-01.mmm.com> Date: Wed, 1 Sep 1999 09:04:46 -0600 Subject: Revision to PIDS Specifications Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: fc1652c33e43bc4e6d7ae149cb9cb133 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. Thanks Santosh Gandhi 3M HIS sgandhi@mmm.com 801-265-4472 Reply-To: "Jon Farmer" From: "Jon Farmer" To: Subject: Issue 2872 need to define type of identifier Date: Thu, 14 Oct 1999 17:49:02 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: @MI!!2S[!!M~V!!92%e9 HL7's person IDs consist of Assigning authority + the "type" of identifier + the id itself>. PIDS QualifiedPersonIDs has DomainName + PersonId Santosh points out the disparity between the HL7 three-part qualified IDs (a CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree we need to rectify the difference, however, I would not add "type" to the PIDS QualifiedPersonId, because (by definition of an ID domain) the ID domain itself is adequate to disambiguate the id value. I think there is a better way to resolve it. Here is my analysis. Functionally, a person id is in fact nothing more than a coded concept (that just needs a unique coding schema and code part) for which the concept is a real world person. I believe that the HL7 use fo the identifier type is a pragmatic necessity for disambiguating the different roles that a newly registered person would play, or the "type" of profile being registeed for the real-world person. Any vendor that uses the same internal identifer domain for all persons in a system (like docs and patients) naturally needed a way to note the "type" of person, or the type of the profile in case there could be a distinct patient profile and doc profile for a given ID. It is functionlly an ATTRIBUTE that is commonly used as part of a primary key for profiles. Therefore I would recommend that, rather than replicate the less-formal HL7 artifact into our IDENTIFIER, lets incorporate it as an attribute of a PROFILE. There are two ways to do this - one that breaks the IDL and one that doesn't. To break the IDL we could change the definition of profile from typedef TraitSeq Profile; to struct Profile { ProfileType enum (patient, person, practitioner, whatever); ProfileTraits TraitSeq }; To keep the IDL intact we could predefine a trait called profileType. Finally, to provide for interoperationwithout requiring either party to break backward compatibility, we could stipulate as guidance (in both forums) an isomorphic transformatiion between the two, that is how to convert person IDs in either direction without info loss or without too much semantic abuse. Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an Any, that can be structured either way. Hwoever, this would introduce healthcare artifiacts in a way that would be totally confusing o PIDS users in other domains. Jon From: "David W. Forslund" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 14 Oct 1999 16:28:10 -0600 (MDT) To: "Jon Farmer" Cc: Subject: Re: Issue 2872 need to define type of identifier In-Reply-To: <001a01bf168d$eef533b0$5ac8869d@JGFNT.toledolink.com> References: <001a01bf168d$eef533b0$5ac8869d@JGFNT.toledolink.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14342.22487.778828.257846@gray.acl.lanl.gov> Reply-To: "David W. Forslund" Content-Type: text/plain; charset=us-ascii X-UIDL: ?eO!!:Hl!!oQnd9N#!!! I believe the best solution here is to have an a Trait which identifies the "type" of a person. It would appear that there is no simple HL7 Trait that corresponds to this. Is this, in fact, the case? If so, we should add a Trait which describes this type, but we must define the "domain" of validity of the type. I see no reason to break the IDL. The issue here also is that a "person" can have multiple types. Should he/she be regarded as a different Id? Should PIDS be used to store provider ids distintct from person id? There is an HL7/ProviderName type, I believe. If this is the case then the type already shows up as a trait. ??? Dave Jon Farmer writes: > HL7's person IDs consist of > > Assigning authority + the "type" of identifier + the id > itself>. > > PIDS QualifiedPersonIDs has > > DomainName + PersonId > > Santosh points out the disparity between the HL7 three-part qualified IDs (a > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree we > need to rectify the difference, however, I would not add "type" to the PIDS > QualifiedPersonId, because (by definition of an ID domain) the ID domain > itself is adequate to disambiguate the id value. > > I think there is a better way to resolve it. Here is my analysis. > > Functionally, a person id is in fact nothing more than a coded concept (that > just needs a unique coding schema and code part) for which the concept is a > real world person. > > I believe that the HL7 use fo the identifier type is a pragmatic necessity > for disambiguating the different roles that a newly registered person would > play, or the "type" of profile being registeed for the real-world person. > Any vendor that uses the same internal identifer domain for all persons in a > system (like docs and patients) naturally needed a way to note the "type" of > person, or the type of the profile in case there could be a distinct patient > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE that > is commonly used as part of a primary key for profiles. > > Therefore I would recommend that, rather than replicate the less-formal HL7 > artifact into our IDENTIFIER, lets incorporate it as an attribute of a > PROFILE. There are two ways to do this - one that breaks the IDL and one > that doesn't. > > To break the IDL we could change the definition of profile from > > typedef TraitSeq Profile; > to > struct Profile { > ProfileType enum (patient, person, practitioner, whatever); > ProfileTraits TraitSeq > }; > > To keep the IDL intact we could predefine a trait called profileType. > > Finally, to provide for interoperationwithout requiring either party to > break backward compatibility, we could stipulate as guidance (in both > forums) an isomorphic transformatiion between the two, that is how to > convert person IDs in either direction without info loss or without too much > semantic abuse. > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an Any, > that can be structured either way. Hwoever, this would introduce healthcare > artifiacts in a way that would be totally confusing o PIDS users in other > domains. > > Jon > Reply-To: "Jon Farmer" From: "Jon Farmer" To: "David W. Forslund" Cc: Subject: Re: Issue 2872 need to define type of identifier Date: Thu, 14 Oct 1999 20:50:38 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: kO3e9fED!!\pBe9No)!! -----Original Message----- From: David W. Forslund To: Jon Farmer Cc: pids-rtf2@omg.org Date: Thursday, October 14, 1999 6:28 PM Subject: Re: Issue 2872 need to define type of identifier >I believe the best solution here is to have an a Trait which identifies >the "type" of a person. It would appear that there is no simple HL7 >Trait that corresponds to this. Is this, in fact, the case? If so, we HL7 has no trait or PID element for this per se, although the RIM has different subtypes of person which are attributed differently. This is why I think the type is really a role or a profile type, rather than an ID type (even though some systems have for whatever reasons chosen to concatenate them into IDs. In practice I like to define distinct domains for patients, practitioners, etc, and then let the correlation Mgr track the correspondence - rather than have multiple "persons" distinquished by type within an ID. Thats not a conceptually valid construct, unless we are defining a "profile identification service (PIDS)". There must be an intention to have exactly one distinct ID value per real-world person. There could be multiple profiles as long as they are consistent >should add a Trait which describes this type, but we must define the >"domain" of validity of the type. I see no reason to break the IDL. Right, it is a discrete, finite (but has to extensible) domain of valid values. > >The issue here also is that a "person" can have multiple types. Should I would stress multiple concurrent roles. To say a person is of some "type" then that precludes the ability to support multiple concurrently applicable types. Just as a person could be BOTH a patient and a practitioner, this is not specifying what type of person they this is specifying their ROLEs - or the subtypes (plural) of person that they instantiate. 1) Therefore one way to approach this is to define a trait called "roles". it designates the roles this person plays. I think it is a mor precise word than "type" for this discussion. "Type" is a hopelessly overloaded term. 2) Another is to assign, for each trait, the roles (plural) for which it applies as an attribute. For example, the family name and given name components are attributes of the (base class) Person role, and a "policy IDs" trait might map to a "beneficiary" role, and a medical specialties trait might map to a practitioners role. I see four possible models here: 1- a trait that conveys the set of roles this person is known to occupy (doesnt affect IDL) 2- multiple profiles (of different profile roles) per person in the same domain, wherein each person still has exactly one id in a given domain; (breaks the candidate typedef and requires a new argument in get_profile) 3 - one composite profile per person within a domain, with traits that are each associated with various roles, e.g. name (which applies to person role) = Joe, medical specialty (which applies to person and practitioner roles) = OBGyn. The RIM reflects this kind of of subtype factoring, and the Message Development Framework (MDF) as used for Version 3 knows how to roll-up subtype attributes into segments or XML attributes, loosely speaking. I think the PMF understnads property inheritance as well. (need extend IDL to record the roles supported for each trait name). 4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein each domain supports exactly one role (Extend IdentifictionComponent so it can tell you what role the domain records) - and let the correlationMgr map them, or else let the client have the responsiblity to not log a practitioner profile into a purely-patient domain. The PIDS you connect to must be a CorrelationMgr to have knowledge of the different roles each of its persons occupies, but it would not know about "multiple profiles per person" as it is now defined. Note, however, that to say that it receives profiles of various roles is NOT the same as saying it has exactly one source domain per role. This is messy because it forces multi-domin semantics into the discussion of roles. Observations (not as in COAS): - the semantics of 1 and 2 are supported by 3, and 4; - the multiple profiles 2 can be derived from 3 but not 4 - 3 and 4 are not mutually exclusive. - all of these break the adopted IDL; 2 does not. Note to any implementors trying to decide which of these breaks your product: - Regardless of the approach taken, it is always valid for an MPI implementation to allocate IDs out of the same "integer-generating sequence" for use in different domains. How do I decide? =================== I like 3 best because it has the richest semantics, is isomorphic with HL7 - even gives HL7 a good reason to use the "identifier type" in their ExternalIDs struct, but functioning as a "profile type". 3 could also actually be turn-the-crank-derived from the RIM - all person attributes and person-subtype attributes would be defined as traits. We could even define a compliance point by referencing a RIM version - and backwards compatibility just happens. Gorgeous V3 interoperablity without information loss in either direction. 1 has an infinite benefit-to-modifications ratio, but 3 has a higher absolute benefit for an extension-only IDL modification >Jon Farmer writes: > > HL7's person IDs consist of > > > > Assigning authority + the "type" of identifier + > the id > > itself>. > > > > PIDS QualifiedPersonIDs has > > > > DomainName + PersonId > > > > Santosh points out the disparity between the HL7 three-part > qualified IDs (a > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally > agree we > > need to rectify the difference, however, I would not add "type" to > the PIDS > > QualifiedPersonId, because (by definition of an ID domain) the ID > domain > > itself is adequate to disambiguate the id value. > > > > I think there is a better way to resolve it. Here is my analysis. > > > > Functionally, a person id is in fact nothing more than a coded > concept (that > > just needs a unique coding schema and code part) for which the > concept is a > > real world person. > > > > I believe that the HL7 use fo the identifier type is a pragmatic necessity > > for disambiguating the different roles that a newly registered > person would > > play, or the "type" of profile being registeed for the real-world person. > > Any vendor that uses the same internal identifer domain for all > persons in a > > system (like docs and patients) naturally needed a way to note the "type" of > > person, or the type of the profile in case there could be a > distinct patient > > profile and doc profile for a given ID. It is functionlly an > ATTRIBUTE that > > is commonly used as part of a primary key for profiles. > > > > Therefore I would recommend that, rather than replicate the > less-formal HL7 > > artifact into our IDENTIFIER, lets incorporate it as an attribute > of a > > PROFILE. There are two ways to do this - one that breaks the IDL > and one > > that doesn't. > > > > To break the IDL we could change the definition of profile from > > > > typedef TraitSeq Profile; > > to > > struct Profile { > > ProfileType enum (patient, person, practitioner, whatever); > > ProfileTraits TraitSeq > > }; > > > > To keep the IDL intact we could predefine a trait called > profileType. > > > > Finally, to provide for interoperationwithout requiring either > party to > > break backward compatibility, we could stipulate as guidance (in > both > > forums) an isomorphic transformatiion between the two, that is how > to > > convert person IDs in either direction without info loss or > without too much > > semantic abuse. > > > > Another IDL-breaking alternative is to make PIDS > QualifiedPersonIDs an Any, > > that can be structured either way. Hwoever, this would introduce healthcare > > artifiacts in a way that would be totally confusing o PIDS users > in other > > domains. > > > > Jon > > > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: "David W. Forslund" cc: "Jon Farmer" , pids-rtf2@omg.org Message-ID: <8625680B.005D7043.00@em-stpmta-01.mmm.com> Date: Fri, 15 Oct 1999 10:59:04 -0600 Subject: Re: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Z;#e9@%Le9#1Pe9B^9!! Jon and David: You both present some interesting points to the definition of the Patient Identifier. I had some thing entirely different in mind when I raised this issue and I am sorry for the confusion. In the PersonIdTraits module - the type associated with the TraitName EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple external identifiers like Tribal Enrollment Number, Sponsor's Social Security Number( for insurance purposes) etc. So in order to fully qualify this identifier, you need the domain (assigning authority) , identifier number and the type of the identifier. So my issue was to define another type for this Trait Name which will be a sequence of (QualifiedPersonId and Type Of Identifier). Thanks Santosh "David W. Forslund" on 10/14/99 04:28:10 PM Please respond to "David W. Forslund" To: "Jon Farmer" cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) Subject: Re: Issue 2872 need to define type of identifier I believe the best solution here is to have an a Trait which identifies the "type" of a person. It would appear that there is no simple HL7 Trait that corresponds to this. Is this, in fact, the case? If so, we should add a Trait which describes this type, but we must define the "domain" of validity of the type. I see no reason to break the IDL. The issue here also is that a "person" can have multiple types. Should he/she be regarded as a different Id? Should PIDS be used to store provider ids distintct from person id? There is an HL7/ProviderName type, I believe. If this is the case then the type already shows up as a trait. ??? Dave Jon Farmer writes: > HL7's person IDs consist of > > Assigning authority + the "type" of identifier + the id > itself>. > > PIDS QualifiedPersonIDs has > > DomainName + PersonId > > Santosh points out the disparity between the HL7 three-part qualified IDs (a > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree we > need to rectify the difference, however, I would not add "type" to the PIDS > QualifiedPersonId, because (by definition of an ID domain) the ID domain > itself is adequate to disambiguate the id value. > > I think there is a better way to resolve it. Here is my analysis. > > Functionally, a person id is in fact nothing more than a coded concept (that > just needs a unique coding schema and code part) for which the concept is a > real world person. > > I believe that the HL7 use fo the identifier type is a pragmatic necessity > for disambiguating the different roles that a newly registered person would > play, or the "type" of profile being registeed for the real-world person. > Any vendor that uses the same internal identifer domain for all persons in a > system (like docs and patients) naturally needed a way to note the "type" of > person, or the type of the profile in case there could be a distinct patient > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE that > is commonly used as part of a primary key for profiles. > > Therefore I would recommend that, rather than replicate the less-formal HL7 > artifact into our IDENTIFIER, lets incorporate it as an attribute of a > PROFILE. There are two ways to do this - one that breaks the IDL and one > that doesn't. > > To break the IDL we could change the definition of profile from > > typedef TraitSeq Profile; > to > struct Profile { > ProfileType enum (patient, person, practitioner, whatever); > ProfileTraits TraitSeq > }; > > To keep the IDL intact we could predefine a trait called profileType. > > Finally, to provide for interoperationwithout requiring either party to > break backward compatibility, we could stipulate as guidance (in both > forums) an isomorphic transformatiion between the two, that is how to > convert person IDs in either direction without info loss or without too much > semantic abuse. > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an Any, > that can be structured either way. Hwoever, this would introduce healthcare > artifiacts in a way that would be totally confusing o PIDS users in other > domains. > > Jon > From: "David W. Forslund" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 15 Oct 1999 13:09:33 -0600 (MDT) To: sgandhi@mmm.com Cc: "Jon Farmer" , pids-rtf2@omg.org Subject: Re: Issue 2872 need to define type of identifier In-Reply-To: <8625680B.005D7043.00@em-stpmta-01.mmm.com> References: <8625680B.005D7043.00@em-stpmta-01.mmm.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14343.31494.535844.242585@gray.acl.lanl.gov> Reply-To: "David W. Forslund" Content-Type: text/plain; charset=us-ascii X-UIDL: eRNd9KnHe91S:e9NM!!! sgandhi@mmm.com writes: > > > Jon and David: > > You both present some interesting points to the definition of the > Patient Identifier. I had some thing entirely different in mind when I > raised this issue and I am sorry for the confusion. > > In the PersonIdTraits module - the type associated with the TraitName > EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple external > identifiers like Tribal Enrollment Number, Sponsor's Social Security > Number( for insurance purposes) etc. So in order to fully qualify this > identifier, you need the domain (assigning authority) , identifier number > and the type of the identifier. So my issue was to define another type for > this Trait Name which will be a sequence of (QualifiedPersonId and Type Of > Identifier). > I think this is easy to accommodate with minimal changes. One way is to include the type in the AuthorityId part of the ExternalId, in which case it is just a suggested way to use it. Another is to provide a more complex ExternalID trait, which would be a minor extension of the supported trait types. There is nothing to prevent that from being done now between people that want to share a proprietary trait defiinition. Another is to use the mechanism I've proposed to allow extensible traits to be defined and understood (without any changes in the IDL!). Thanks for your clarification, Dave > Thanks > > Santosh > > > > > "David W. Forslund" on 10/14/99 04:28:10 PM > > Please respond to "David W. Forslund" > > > To: "Jon Farmer" > cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > Subject: Re: Issue 2872 need to define type of identifier > > > > > I believe the best solution here is to have an a Trait which identifies > the "type" of a person. It would appear that there is no simple HL7 > Trait that corresponds to this. Is this, in fact, the case? If so, we > should add a Trait which describes this type, but we must define the > "domain" of validity of the type. I see no reason to break the IDL. > > The issue here also is that a "person" can have multiple types. Should > he/she be regarded as a different Id? Should PIDS be used to store > provider ids distintct from person id? There is an HL7/ProviderName > type, I believe. If this is the case then the type already shows up > as a trait. ??? > > Dave > > Jon Farmer writes: > > HL7's person IDs consist of > > > > Assigning authority + the "type" of identifier + the id > > itself>. > > > > PIDS QualifiedPersonIDs has > > > > DomainName + PersonId > > > > Santosh points out the disparity between the HL7 three-part qualified > IDs (a > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree > we > > need to rectify the difference, however, I would not add "type" to the > PIDS > > QualifiedPersonId, because (by definition of an ID domain) the ID domain > > itself is adequate to disambiguate the id value. > > > > I think there is a better way to resolve it. Here is my analysis. > > > > Functionally, a person id is in fact nothing more than a coded concept > (that > > just needs a unique coding schema and code part) for which the concept > is a > > real world person. > > > > I believe that the HL7 use fo the identifier type is a pragmatic > necessity > > for disambiguating the different roles that a newly registered person > would > > play, or the "type" of profile being registeed for the real-world > person. > > Any vendor that uses the same internal identifer domain for all persons > in a > > system (like docs and patients) naturally needed a way to note the > "type" of > > person, or the type of the profile in case there could be a distinct > patient > > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE > that > > is commonly used as part of a primary key for profiles. > > > > Therefore I would recommend that, rather than replicate the less-formal > HL7 > > artifact into our IDENTIFIER, lets incorporate it as an attribute of a > > PROFILE. There are two ways to do this - one that breaks the IDL and > one > > that doesn't. > > > > To break the IDL we could change the definition of profile from > > > > typedef TraitSeq Profile; > > to > > struct Profile { > > ProfileType enum (patient, person, practitioner, whatever); > > ProfileTraits TraitSeq > > }; > > > > To keep the IDL intact we could predefine a trait called profileType. > > > > Finally, to provide for interoperationwithout requiring either party to > > break backward compatibility, we could stipulate as guidance (in both > > forums) an isomorphic transformatiion between the two, that is how to > > convert person IDs in either direction without info loss or without too > much > > semantic abuse. > > > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an > Any, > > that can be structured either way. Hwoever, this would introduce > healthcare > > artifiacts in a way that would be totally confusing o PIDS users in > other > > domains. > > > > Jon > > > > > > > > Reply-To: "Jon Farmer" From: "Jon Farmer" To: "David W. Forslund" , Cc: Subject: Re: Issue 2872 need to define type of identifier Date: Fri, 15 Oct 1999 16:04:42 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )nJe9pC-e9_Ao!!Cf$!! inline -----Original Message----- From: David W. Forslund To: sgandhi@mmm.com Cc: Jon Farmer ; pids-rtf2@omg.org Date: Friday, October 15, 1999 3:34 PM Subject: Re: Issue 2872 need to define type of identifier >sgandhi@mmm.com writes: > > > > > > Jon and David: > > > > You both present some interesting points to the > definition of the > > Patient Identifier. I had some thing entirely different in mind > when I > > raised this issue and I am sorry for the confusion. > > > > In the PersonIdTraits module - the type associated with the > TraitName > > EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple external > > identifiers like Tribal Enrollment Number, Sponsor's Social > Security > > Number( for insurance purposes) etc. So in order to fully qualify > this > > identifier, you need the domain (assigning authority) , > identifier number > > and the type of the identifier. So my issue was to define another > type for > > this Trait Name which will be a sequence of (QualifiedPersonId and > Type Of > > Identifier). > > >I think this is easy to accommodate with minimal changes. One way is > to >include the type in the AuthorityId part of the ExternalId, in which >case it is just a suggested way to use it. Another is to provide a > more >complex ExternalID trait, which would be a minor extension of the >supported trait types. There is nothing to prevent that from being > done >now between people that want to share a proprietary trait > defiinition. I think we're getting closer, but until we know what we mean by type, I think we will not able to confirm the appropriateness of a proposal. However, I would still ask here, could multiple types apply? If we use the RIM classes as roles, then there would only need to be one (because supertypes are implied by the RIM) but then that limits the meaningfulness of this thing to healthcare, unless we namespace-qualify the role names. I don;t want to find myself caring more about "where it fits-without breaking the IDL" than "what it is/what it means". I propose that anyone who proposes a solution must also supply a working definition of what this thing IS. >Another is to use the mechanism I've proposed to allow extensible traits >to be defined and understood (without any changes in the IDL!). > >Thanks for your clarification, > >Dave > > > Thanks > > > > Santosh > > > > > > > > > > "David W. Forslund" on 10/14/99 04:28:10 PM > > > > Please respond to "David W. Forslund" > > > > > > To: "Jon Farmer" > > cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > > Subject: Re: Issue 2872 need to define type of identifier > > > > > > > > > > I believe the best solution here is to have an a Trait which identifies > > the "type" of a person. It would appear that there is no simple HL7 > > Trait that corresponds to this. Is this, in fact, the case? If so, we > > should add a Trait which describes this type, but we must define the > > "domain" of validity of the type. I see no reason to break the IDL. > > > > The issue here also is that a "person" can have multiple types. Should > > he/she be regarded as a different Id? Should PIDS be used to store > > provider ids distintct from person id? There is an HL7/ProviderName > > type, I believe. If this is the case then the type already shows up > > as a trait. ??? > > > > Dave > > > > Jon Farmer writes: > > > HL7's person IDs consist of > > > > > > Assigning authority + the "type" of identifier + the id > > > itself>. > > > > > > PIDS QualifiedPersonIDs has > > > > > > DomainName + PersonId > > > > > > Santosh points out the disparity between the HL7 three-part qualified > > IDs (a > > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree > > we > > > need to rectify the difference, however, I would not add "type" to the > > PIDS > > > QualifiedPersonId, because (by definition of an ID domain) the ID domain > > > itself is adequate to disambiguate the id value. > > > > > > I think there is a better way to resolve it. Here is my analysis. > > > > > > Functionally, a person id is in fact nothing more than a coded concept > > (that > > > just needs a unique coding schema and code part) for which the concept > > is a > > > real world person. > > > > > > I believe that the HL7 use fo the identifier type is a pragmatic > > necessity > > > for disambiguating the different roles that a newly registered person > > would > > > play, or the "type" of profile being registeed for the real-world > > person. > > > Any vendor that uses the same internal identifer domain for all persons > > in a > > > system (like docs and patients) naturally needed a way to note the > > "type" of > > > person, or the type of the profile in case there could be a distinct > > patient > > > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE > > that > > > is commonly used as part of a primary key for profiles. > > > > > > Therefore I would recommend that, rather than replicate the less-formal > > HL7 > > > artifact into our IDENTIFIER, lets incorporate it as an attribute of a > > > PROFILE. There are two ways to do this - one that breaks the IDL and > > one > > > that doesn't. > > > > > > To break the IDL we could change the definition of profile from > > > > > > typedef TraitSeq Profile; > > > to > > > struct Profile { > > > ProfileType enum (patient, person, practitioner, whatever); > > > ProfileTraits TraitSeq > > > }; > > > > > > To keep the IDL intact we could predefine a trait called profileType. > > > > > > Finally, to provide for interoperationwithout requiring either party to > > > break backward compatibility, we could stipulate as guidance (in both > > > forums) an isomorphic transformatiion between the two, that is how to > > > convert person IDs in either direction without info loss or without too > > much > > > semantic abuse. > > > > > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an > > Any, > > > that can be structured either way. Hwoever, this would introduce > > healthcare > > > artifiacts in a way that would be totally confusing o PIDS users in > > other > > > domains. > > > > > > Jon > > > > > > > > > > > > > > > > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: "Jon Farmer" cc: "David W. Forslund" , pids-rtf2@omg.org Message-ID: <8625680B.00715D0C.00@em-stpmta-01.mmm.com> Date: Fri, 15 Oct 1999 14:36:43 -0600 Subject: Re: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: o#nd9kMjd9;O_!!-j9e9 Jon and David - The requirements I have so far - which prompted me to raise this issue - do not lead to multiple types for the same External_ID - In fact the type needs to be unique for every External_ID - though the domain need not be unique. For example , the Driver's License number (Type) is unique though the domain (Different States issuing the license number in this case) may not be unique. "Jon Farmer" on 10/15/99 02:04:42 PM Please respond to "Jon Farmer" To: "David W. Forslund" Santosh Gandhi/HI-HealthInfo/3M/US cc: pids-rtf2@omg.org Subject: Re: Issue 2872 need to define type of identifier inline -----Original Message----- From: David W. Forslund To: sgandhi@mmm.com Cc: Jon Farmer ; pids-rtf2@omg.org Date: Friday, October 15, 1999 3:34 PM Subject: Re: Issue 2872 need to define type of identifier >sgandhi@mmm.com writes: > > > > > > Jon and David: > > > > You both present some interesting points to the > definition of the > > Patient Identifier. I had some thing entirely different in mind > when I > > raised this issue and I am sorry for the confusion. > > > > In the PersonIdTraits module - the type associated with the > TraitName > > EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple external > > identifiers like Tribal Enrollment Number, Sponsor's Social > Security > > Number( for insurance purposes) etc. So in order to fully qualify > this > > identifier, you need the domain (assigning authority) , > identifier number > > and the type of the identifier. So my issue was to define another > type for > > this Trait Name which will be a sequence of (QualifiedPersonId and > Type Of > > Identifier). > > >I think this is easy to accommodate with minimal changes. One way is > to >include the type in the AuthorityId part of the ExternalId, in which >case it is just a suggested way to use it. Another is to provide a > more >complex ExternalID trait, which would be a minor extension of the >supported trait types. There is nothing to prevent that from being > done >now between people that want to share a proprietary trait > defiinition. I think we're getting closer, but until we know what we mean by type, I think we will not able to confirm the appropriateness of a proposal. However, I would still ask here, could multiple types apply? If we use the RIM classes as roles, then there would only need to be one (because supertypes are implied by the RIM) but then that limits the meaningfulness of this thing to healthcare, unless we namespace-qualify the role names. I don;t want to find myself caring more about "where it fits-without breaking the IDL" than "what it is/what it means". I propose that anyone who proposes a solution must also supply a working definition of what this thing IS. >Another is to use the mechanism I've proposed to allow extensible traits >to be defined and understood (without any changes in the IDL!). > >Thanks for your clarification, > >Dave > > > Thanks > > > > Santosh > > > > > > > > > > "David W. Forslund" on 10/14/99 04:28:10 PM > > > > Please respond to "David W. Forslund" > > > > > > To: "Jon Farmer" > > cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > > Subject: Re: Issue 2872 need to define type of identifier > > > > > > > > > > I believe the best solution here is to have an a Trait which identifies > > the "type" of a person. It would appear that there is no simple HL7 > > Trait that corresponds to this. Is this, in fact, the case? If so, we > > should add a Trait which describes this type, but we must define the > > "domain" of validity of the type. I see no reason to break the IDL. > > > > The issue here also is that a "person" can have multiple types. Should > > he/she be regarded as a different Id? Should PIDS be used to store > > provider ids distintct from person id? There is an HL7/ProviderName > > type, I believe. If this is the case then the type already shows up > > as a trait. ??? > > > > Dave > > > > Jon Farmer writes: > > > HL7's person IDs consist of > > > > > > Assigning authority + the "type" of identifier + the id > > > itself>. > > > > > > PIDS QualifiedPersonIDs has > > > > > > DomainName + PersonId > > > > > > Santosh points out the disparity between the HL7 three-part qualified > > IDs (a > > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree > > we > > > need to rectify the difference, however, I would not add "type" to the > > PIDS > > > QualifiedPersonId, because (by definition of an ID domain) the ID domain > > > itself is adequate to disambiguate the id value. > > > > > > I think there is a better way to resolve it. Here is my analysis. > > > > > > Functionally, a person id is in fact nothing more than a coded concept > > (that > > > just needs a unique coding schema and code part) for which the concept > > is a > > > real world person. > > > > > > I believe that the HL7 use fo the identifier type is a pragmatic > > necessity > > > for disambiguating the different roles that a newly registered person > > would > > > play, or the "type" of profile being registeed for the real-world > > person. > > > Any vendor that uses the same internal identifer domain for all persons > > in a > > > system (like docs and patients) naturally needed a way to note the > > "type" of > > > person, or the type of the profile in case there could be a distinct > > patient > > > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE > > that > > > is commonly used as part of a primary key for profiles. > > > > > > Therefore I would recommend that, rather than replicate the less-formal > > HL7 > > > artifact into our IDENTIFIER, lets incorporate it as an attribute of a > > > PROFILE. There are two ways to do this - one that breaks the IDL and > > one > > > that doesn't. > > > > > > To break the IDL we could change the definition of profile from > > > > > > typedef TraitSeq Profile; > > > to > > > struct Profile { > > > ProfileType enum (patient, person, practitioner, whatever); > > > ProfileTraits TraitSeq > > > }; > > > > > > To keep the IDL intact we could predefine a trait called profileType. > > > > > > Finally, to provide for interoperationwithout requiring either party to > > > break backward compatibility, we could stipulate as guidance (in both > > > forums) an isomorphic transformatiion between the two, that is how to > > > convert person IDs in either direction without info loss or without too > > much > > > semantic abuse. > > > > > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an > > Any, > > > that can be structured either way. Hwoever, this would introduce > > healthcare > > > artifiacts in a way that would be totally confusing o PIDS users in > > other > > > domains. > > > > > > Jon > > > > > > > > > > > > > > > > From: "David W. Forslund" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 15 Oct 1999 14:31:35 -0600 (MDT) To: "Jon Farmer" Cc: , Subject: Re: Issue 2872 need to define type of identifier In-Reply-To: <004c01bf1748$863508d0$161e85cd@JGFNT.toledolink.com> References: <004c01bf1748$863508d0$161e85cd@JGFNT.toledolink.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14343.36251.919310.217194@gray.acl.lanl.gov> Reply-To: "David W. Forslund" Content-Type: text/plain; charset=us-ascii X-UIDL: MDmd9EA(!!b1B!!Mm!e9 Jon Farmer writes: > inline > -----Original Message----- > From: David W. Forslund > To: sgandhi@mmm.com > Cc: Jon Farmer ; pids-rtf2@omg.org > Date: Friday, October 15, 1999 3:34 PM > Subject: Re: Issue 2872 need to define type of identifier > > > >sgandhi@mmm.com writes: > > > > > > > > > Jon and David: > > > > > > You both present some interesting points to the definition of > the > > > Patient Identifier. I had some thing entirely different in mind when I > > > raised this issue and I am sorry for the confusion. > > > > > > In the PersonIdTraits module - the type associated with the TraitName > > > EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple > external > > > identifiers like Tribal Enrollment Number, Sponsor's Social Security > > > Number( for insurance purposes) etc. So in order to fully qualify this > > > identifier, you need the domain (assigning authority) , identifier > number > > > and the type of the identifier. So my issue was to define another type > for > > > this Trait Name which will be a sequence of (QualifiedPersonId and Type > Of > > > Identifier). > > > > >I think this is easy to accommodate with minimal changes. One way is to > >include the type in the AuthorityId part of the ExternalId, in which > >case it is just a suggested way to use it. Another is to provide a more > >complex ExternalID trait, which would be a minor extension of the > >supported trait types. There is nothing to prevent that from being done > >now between people that want to share a proprietary trait defiinition. > > I think we're getting closer, but until we know what we mean by type, I > think we will not able to confirm the appropriateness of a proposal. > However, I would still ask here, could multiple types apply? If we use the > RIM classes as roles, then there would only need to be one (because > supertypes are implied by the RIM) but then that limits the meaningfulness > of this thing to healthcare, unless we namespace-qualify the role names. > The first two suggestions I made are easy to implement for a site, but don't necessarily provide interoperablity. The user can have their own meaning of "type". These don't necessarily have anything to do with the RTF. If we want to define a new Trait with an additional characteristic (called type) that anyone can use, then we need to figure out what we mean by type. I believe this is out of scope of the RTF, but would involve an RFP, and the one proposed for demographics or managing providers, could easily be the right place for it. > I don;t want to find myself caring more about "where it fits-without > breaking the IDL" than "what it is/what it means". I propose that anyone > who proposes a solution must also supply a working definition of what this > thing IS. I have no desire to avoid "what it is/means". I'm just pointing out that one can do this today in a full extensible way. The spec allows for this "ambiguity". I would like to find a way to define constraints on this extensibility so that we can retain interoperability. Since nested arrays of Traits are allowed in the current spec (IDL), we need to say something about this ambiguity as a result in this this RTF. Dave > > >Another is to use the mechanism I've proposed to allow extensible traits > >to be defined and understood (without any changes in the IDL!). > > > > > > >Thanks for your clarification, > > > >Dave > > > > > Thanks > > > > > > Santosh > > > > > > > > > > > > > > > "David W. Forslund" on 10/14/99 04:28:10 PM > > > > > > Please respond to "David W. Forslund" > > > > > > > > > To: "Jon Farmer" > > > cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > > > Subject: Re: Issue 2872 need to define type of identifier > > > > > > > > > > > > > > > I believe the best solution here is to have an a Trait which identifies > > > the "type" of a person. It would appear that there is no simple HL7 > > > Trait that corresponds to this. Is this, in fact, the case? If so, we > > > should add a Trait which describes this type, but we must define the > > > "domain" of validity of the type. I see no reason to break the IDL. > > > > > > The issue here also is that a "person" can have multiple types. Should > > > he/she be regarded as a different Id? Should PIDS be used to store > > > provider ids distintct from person id? There is an HL7/ProviderName > > > type, I believe. If this is the case then the type already shows up > > > as a trait. ??? > > > > > > Dave > > > > > > Jon Farmer writes: > > > > HL7's person IDs consist of > > > > > > > > Assigning authority + the "type" of identifier + the > id > > > > itself>. > > > > > > > > PIDS QualifiedPersonIDs has > > > > > > > > DomainName + PersonId > > > > > > > > Santosh points out the disparity between the HL7 three-part qualified > > > IDs (a > > > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally > agree > > > we > > > > need to rectify the difference, however, I would not add "type" to > the > > > PIDS > > > > QualifiedPersonId, because (by definition of an ID domain) the ID > domain > > > > itself is adequate to disambiguate the id value. > > > > > > > > I think there is a better way to resolve it. Here is my analysis. > > > > > > > > Functionally, a person id is in fact nothing more than a coded > concept > > > (that > > > > just needs a unique coding schema and code part) for which the > concept > > > is a > > > > real world person. > > > > > > > > I believe that the HL7 use fo the identifier type is a pragmatic > > > necessity > > > > for disambiguating the different roles that a newly registered person > > > would > > > > play, or the "type" of profile being registeed for the real-world > > > person. > > > > Any vendor that uses the same internal identifer domain for all > persons > > > in a > > > > system (like docs and patients) naturally needed a way to note the > > > "type" of > > > > person, or the type of the profile in case there could be a distinct > > > patient > > > > profile and doc profile for a given ID. It is functionlly an > ATTRIBUTE > > > that > > > > is commonly used as part of a primary key for profiles. > > > > > > > > Therefore I would recommend that, rather than replicate the > less-formal > > > HL7 > > > > artifact into our IDENTIFIER, lets incorporate it as an attribute of > a > > > > PROFILE. There are two ways to do this - one that breaks the IDL and > > > one > > > > that doesn't. > > > > > > > > To break the IDL we could change the definition of profile from > > > > > > > > typedef TraitSeq Profile; > > > > to > > > > struct Profile { > > > > ProfileType enum (patient, person, practitioner, whatever); > > > > ProfileTraits TraitSeq > > > > }; > > > > > > > > To keep the IDL intact we could predefine a trait called profileType. > > > > > > > > Finally, to provide for interoperationwithout requiring either party > to > > > > break backward compatibility, we could stipulate as guidance (in both > > > > forums) an isomorphic transformatiion between the two, that is how to > > > > convert person IDs in either direction without info loss or without > too > > > much > > > > semantic abuse. > > > > > > > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs > an > > > Any, > > > > that can be structured either way. Hwoever, this would introduce > > > healthcare > > > > artifiacts in a way that would be totally confusing o PIDS users in > > > other > > > > domains. > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 15 Oct 1999 16:04:39 -0600 To: sgandhi@mmm.com, "Jon Farmer" From: David Forslund Subject: Re: Issue 2872 need to define type of identifier Cc: pids-rtf2@omg.org In-Reply-To: <8625680B.00715D0C.00@em-stpmta-01.mmm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: i?hd9Bec!!f2=!!)*bd9 That is my impression which is why I suggested some of the solutions I did. You can do this now with PIDS with no change in the specification. Just include the type as a "sub-domain" in the ExternalID. Dave At 02:36 PM 10/15/99 -0600, sgandhi@mmm.com wrote: >Jon and David - The requirements I have so far - which prompted me to raise >this issue - do not lead to multiple types for the same External_ID - In >fact the type needs to be unique for every External_ID - though the domain >need not be unique. For example , the Driver's License number (Type) is >unique though the domain (Different States issuing the license number in >this case) may not be unique. > > > > > >"Jon Farmer" on 10/15/99 02:04:42 PM > >Please respond to "Jon Farmer" > > >To: "David W. Forslund" > Santosh Gandhi/HI-HealthInfo/3M/US >cc: pids-rtf2@omg.org >Subject: Re: Issue 2872 need to define type of identifier > > > > >inline >-----Original Message----- >From: David W. Forslund >To: sgandhi@mmm.com >Cc: Jon Farmer ; pids-rtf2@omg.org >Date: Friday, October 15, 1999 3:34 PM >Subject: Re: Issue 2872 need to define type of identifier > > > >sgandhi@mmm.com writes: > > > > > > > > > Jon and David: > > > > > > You both present some interesting points to the definition of >the > > > Patient Identifier. I had some thing entirely different in mind when I > > > raised this issue and I am sorry for the confusion. > > > > > > In the PersonIdTraits module - the type associated with the TraitName > > > EXTERNAL_IDS is QualifiedPersonIdSeq. A person can have multiple >external > > > identifiers like Tribal Enrollment Number, Sponsor's Social Security > > > Number( for insurance purposes) etc. So in order to fully qualify this > > > identifier, you need the domain (assigning authority) , identifier >number > > > and the type of the identifier. So my issue was to define another type >for > > > this Trait Name which will be a sequence of (QualifiedPersonId and Type >Of > > > Identifier). > > > > >I think this is easy to accommodate with minimal changes. One way is to > >include the type in the AuthorityId part of the ExternalId, in which > >case it is just a suggested way to use it. Another is to provide a more > >complex ExternalID trait, which would be a minor extension of the > >supported trait types. There is nothing to prevent that from being done > >now between people that want to share a proprietary trait defiinition. > >I think we're getting closer, but until we know what we mean by type, I >think we will not able to confirm the appropriateness of a proposal. >However, I would still ask here, could multiple types apply? If we use the >RIM classes as roles, then there would only need to be one (because >supertypes are implied by the RIM) but then that limits the meaningfulness >of this thing to healthcare, unless we namespace-qualify the role names. > >I don;t want to find myself caring more about "where it fits-without >breaking the IDL" than "what it is/what it means". I propose that anyone >who proposes a solution must also supply a working definition of what this >thing IS. > > >Another is to use the mechanism I've proposed to allow extensible traits > >to be defined and understood (without any changes in the IDL!). > > > > > > >Thanks for your clarification, > > > >Dave > > > > > Thanks > > > > > > Santosh > > > > > > > > > > > > > > > "David W. Forslund" on 10/14/99 04:28:10 PM > > > > > > Please respond to "David W. Forslund" > > > > > > > > > To: "Jon Farmer" > > > cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > > > Subject: Re: Issue 2872 need to define type of identifier > > > > > > > > > > > > > > > I believe the best solution here is to have an a Trait which identifies > > > the "type" of a person. It would appear that there is no simple HL7 > > > Trait that corresponds to this. Is this, in fact, the case? If so, we > > > should add a Trait which describes this type, but we must define the > > > "domain" of validity of the type. I see no reason to break the IDL. > > > > > > The issue here also is that a "person" can have multiple types. Should > > > he/she be regarded as a different Id? Should PIDS be used to store > > > provider ids distintct from person id? There is an HL7/ProviderName > > > type, I believe. If this is the case then the type already shows up > > > as a trait. ??? > > > > > > Dave > > > > > > Jon Farmer writes: > > > > HL7's person IDs consist of > > > > > > > > Assigning authority + the "type" of identifier + the >id > > > > itself>. > > > > > > > > PIDS QualifiedPersonIDs has > > > > > > > > DomainName + PersonId > > > > > > > > Santosh points out the disparity between the HL7 three-part >qualified > > > IDs (a > > > > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >agree > > > we > > > > need to rectify the difference, however, I would not add "type" to >the > > > PIDS > > > > QualifiedPersonId, because (by definition of an ID domain) the ID >domain > > > > itself is adequate to disambiguate the id value. > > > > > > > > I think there is a better way to resolve it. Here is my analysis. > > > > > > > > Functionally, a person id is in fact nothing more than a coded >concept > > > (that > > > > just needs a unique coding schema and code part) for which the >concept > > > is a > > > > real world person. > > > > > > > > I believe that the HL7 use fo the identifier type is a pragmatic > > > necessity > > > > for disambiguating the different roles that a newly registered >person > > > would > > > > play, or the "type" of profile being registeed for the real-world > > > person. > > > > Any vendor that uses the same internal identifer domain for all >persons > > > in a > > > > system (like docs and patients) naturally needed a way to note the > > > "type" of > > > > person, or the type of the profile in case there could be a distinct > > > patient > > > > profile and doc profile for a given ID. It is functionlly an >ATTRIBUTE > > > that > > > > is commonly used as part of a primary key for profiles. > > > > > > > > Therefore I would recommend that, rather than replicate the >less-formal > > > HL7 > > > > artifact into our IDENTIFIER, lets incorporate it as an attribute of >a > > > > PROFILE. There are two ways to do this - one that breaks the IDL >and > > > one > > > > that doesn't. > > > > > > > > To break the IDL we could change the definition of profile from > > > > > > > > typedef TraitSeq Profile; > > > > to > > > > struct Profile { > > > > ProfileType enum (patient, person, practitioner, whatever); > > > > ProfileTraits TraitSeq > > > > }; > > > > > > > > To keep the IDL intact we could predefine a trait called >profileType. > > > > > > > > Finally, to provide for interoperationwithout requiring either party >to > > > > break backward compatibility, we could stipulate as guidance (in >both > > > > forums) an isomorphic transformatiion between the two, that is how >to > > > > convert person IDs in either direction without info loss or without >too > > > much > > > > semantic abuse. > > > > > > > > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >an > > > Any, > > > > that can be structured either way. Hwoever, this would introduce > > > healthcare > > > > artifiacts in a way that would be totally confusing o PIDS users in > > > other > > > > domains. > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reply-To: "Jon Farmer" From: "Jon Farmer" To: "Jon Farmer" , "David W. Forslund" Cc: Subject: Re: Issue 2872 need to define type of identifier Date: Thu, 21 Oct 1999 18:59:48 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: iVR!!L&Ud9/#Zd9ma To: David W. Forslund Cc: pids-rtf2@omg.org Date: Thursday, October 14, 1999 8:50 PM Subject: Re: Issue 2872 need to define type of identifier > >-----Original Message----- >From: David W. Forslund >To: Jon Farmer >Cc: pids-rtf2@omg.org >Date: Thursday, October 14, 1999 6:28 PM >Subject: Re: Issue 2872 need to define type of identifier > > >>I believe the best solution here is to have an a Trait which identifies >>the "type" of a person. It would appear that there is no simple HL7 >>Trait that corresponds to this. Is this, in fact, the case? If so, we > >HL7 has no trait or PID element for this per se, although the RIM has >different subtypes of person which are attributed differently. This is why >I think the type is really a role or a profile type, rather than an ID type >(even >though some systems have for whatever reasons chosen to concatenate them >into IDs. In practice I like to define distinct domains for patients, >practitioners, etc, >and then let the correlation Mgr track the correspondence - rather than have >multiple >"persons" distinquished by type within an ID. Thats not a conceptually >valid construct, >unless we are defining a "profile identification service (PIDS)". > >There must be an intention to have exactly one distinct ID value per >real-world person. >There could be multiple profiles as long as they are consistent > >>should add a Trait which describes this type, but we must define the >>"domain" of validity of the type. I see no reason to break the IDL. > >Right, it is a discrete, finite (but has to extensible) domain of valid >values. > >> >>The issue here also is that a "person" can have multiple types. Should >I would stress multiple concurrent roles. To say a person is of some "type" >then that >precludes the ability to support multiple concurrently applicable types. >Just as a person >could be BOTH a patient and a practitioner, this is not specifying what type >of person they >this is specifying their ROLEs - or the subtypes (plural) of person that >they instantiate. > >1) Therefore one way to approach this is to define a trait called "roles". >it designates the roles this person plays. I think it is a mor precise word >than "type" for this discussion. "Type" is a hopelessly overloaded term. > >2) Another is to assign, for each trait, the roles (plural) for which it >applies as an attribute. For example, >the family name and given name components are attributes of the (base class) >Person role, >and a "policy IDs" trait might map to a "beneficiary" role, and a medical >specialties trait might map to >a practitioners role. > > >I see four possible models here: > >1- a trait that conveys the set of roles this person is known to occupy >(doesnt affect IDL) > >2- multiple profiles (of different profile roles) per person in the same >domain, wherein each person still has exactly one id in a given domain; >(breaks the candidate typedef and requires a new argument in get_profile) > >3 - one composite profile per person within a domain, with traits that are >each associated with various roles, e.g. name (which applies to person role) >= Joe, medical specialty (which applies to person and practitioner roles) = >OBGyn. The RIM reflects this kind of of subtype factoring, and the Message >Development Framework (MDF) as used for Version 3 knows how to roll-up >subtype attributes into segments or XML attributes, loosely speaking. I >think the PMF understnads property inheritance as well. (need extend IDL to >record the roles supported for each trait name). > >4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein each >domain supports exactly one role (Extend IdentifictionComponent so it can >tell you what role the domain records) - and let the correlationMgr map >them, or else let the client have the responsiblity to not log a >practitioner profile into a purely-patient domain. The PIDS you connect to >must be a CorrelationMgr to have knowledge of the different roles each of >its persons occupies, but it would not know about "multiple profiles per >person" as it is now defined. Note, however, that to say that it receives >profiles of various roles is NOT the same as saying it has exactly one >source domain per role. This is messy because it forces multi-domin >semantics into the discussion of roles. > >Observations (not as in COAS): >- the semantics of 1 and 2 are supported by 3, and 4; >- the multiple profiles 2 can be derived from 3 but not 4 >- 3 and 4 are not mutually exclusive. >- all of these break the adopted IDL; 2 does not. > >Note to any implementors trying to decide which of these breaks your >product: >- Regardless of the approach taken, it is always valid for an MPI >implementation to allocate IDs out of the same "integer-generating sequence" >for use in different domains. > > >How do I decide? >=================== >I like 3 best because it has the richest semantics, is isomorphic with HL7 - >even gives HL7 a good reason to use the "identifier type" in their >ExternalIDs struct, but functioning as a "profile type". 3 could also >actually be turn-the-crank-derived from the RIM - all person attributes and >person-subtype attributes would be defined as traits. We could even define >a compliance point by referencing a RIM version - and backwards >compatibility just happens. Gorgeous V3 interoperablity without >information loss in either direction. > >1 has an infinite benefit-to-modifications ratio, but 3 has a higher >absolute benefit for an extension-only IDL modification > >>Jon Farmer writes: >> > HL7's person IDs consist of >> > >> > Assigning authority + the "type" of identifier + the id >> > itself>. >> > >> > PIDS QualifiedPersonIDs has >> > >> > DomainName + PersonId >> > >> > Santosh points out the disparity between the HL7 three-part qualified >IDs (a >> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree >we >> > need to rectify the difference, however, I would not add "type" to the >PIDS >> > QualifiedPersonId, because (by definition of an ID domain) the ID domain >> > itself is adequate to disambiguate the id value. >> > >> > I think there is a better way to resolve it. Here is my analysis. >> > >> > Functionally, a person id is in fact nothing more than a coded concept >(that >> > just needs a unique coding schema and code part) for which the concept >is a >> > real world person. >> > >> > I believe that the HL7 use fo the identifier type is a pragmatic >necessity >> > for disambiguating the different roles that a newly registered person >would >> > play, or the "type" of profile being registeed for the real-world >person. >> > Any vendor that uses the same internal identifer domain for all persons >in a >> > system (like docs and patients) naturally needed a way to note the >"type" of >> > person, or the type of the profile in case there could be a distinct >patient >> > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE >that >> > is commonly used as part of a primary key for profiles. >> > >> > Therefore I would recommend that, rather than replicate the less-formal >HL7 >> > artifact into our IDENTIFIER, lets incorporate it as an attribute of a >> > PROFILE. There are two ways to do this - one that breaks the IDL and >one >> > that doesn't. >> > >> > To break the IDL we could change the definition of profile from >> > >> > typedef TraitSeq Profile; >> > to >> > struct Profile { >> > ProfileType enum (patient, person, practitioner, whatever); >> > ProfileTraits TraitSeq >> > }; >> > >> > To keep the IDL intact we could predefine a trait called profileType. >> > >> > Finally, to provide for interoperationwithout requiring either party to >> > break backward compatibility, we could stipulate as guidance (in both >> > forums) an isomorphic transformatiion between the two, that is how to >> > convert person IDs in either direction without info loss or without too >much >> > semantic abuse. >> > >> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an >Any, >> > that can be structured either way. Hwoever, this would introduce >healthcare >> > artifiacts in a way that would be totally confusing o PIDS users in >other >> > domains. >> > >> > Jon >> > >> > Reply-To: "Jon Farmer" From: "Jon Farmer" To: "PIDS RTF" Subject: Fw: Issue 2872 need to define type of identifier Date: Mon, 25 Oct 1999 16:24:56 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3"`!!N/ld9Jk=!!%)J!! Santosh has specified that identifier types among a set of ExternalIDs must be unique. If I understand this correctly, this means that no two of the Qualified Person IDs in a given ExternalIDs trait can have the same identifier type. I suspect that we cannot accept this assumption, since there are an arbitrarily large number of id-assigners for a given real-world person, and there is no way they coordinate wtih each other tomake sure that only one of them is "using" the SSN or the MRN. I think it's precisely this autonomy that makes correlation necessary in the first place. Santosh can you defend the uniqueness assumption? or maybe I misunderstood, in which case I probably need an example. Jon -----Original Message----- From: Jon Farmer To: Jon Farmer ; David W. Forslund Cc: pids-rtf2@omg.org Date: Thursday, October 21, 1999 7:11 PM Subject: Re: Issue 2872 need to define type of identifier >Santosh and others, > >I think Dave's proposal not only meets your needs, but also the "role" >oriented kind of thing I was trying to force-fit into it. Here is how I >would summarize the various requirements (the ones you raised and I raised) >and how Dave's solution could address them. > >1) in cases where an "identifier type" is NEEDED to uniquely identify the id >domain, it could be concatenated by the client to construct the existing ID >domain - as the client sees fit. This would keep us from contaminating the >definition of an ID domain. > >2) For the case in which the type is not needed in order to make the ID >domain unambiguous, but the application environment still needs a way to >"qualify" the ID, as Santosh descibed - we could define a Trait to carry it, >or an enhanced trait like External IDs that carries the "enhanced External >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback >here as to what that would be called. Would this approach suffice for the >GCPR? I think this is most pivotal remaining issue in the whole RTF. > >3) to convey the notion of roles (which is implied in some of the HL7 values >for type) without mixing it up with the type, a distinct trait perhaps >called roles or even relationships could be defined by local agreement. > >It appears these three approaches meet all our requirements without breaking >the existing IDL. We might consider now whether we need to define the new >traits ( 2 and 3) as "new standard traits", or just leave it up to local >agreement. > >Dave F points out that in the Party Management Facility (PMF), roles and >relationships are explicit in IDL as first class objects (interfaces). Hey >Dave - can the trait's ANY carry an IOR? > > > >-----Original Message----- >From: Jon Farmer >To: David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 14, 1999 8:50 PM >Subject: Re: Issue 2872 need to define type of identifier > > >> >>-----Original Message----- >>From: David W. Forslund >>To: Jon Farmer >>Cc: pids-rtf2@omg.org >>Date: Thursday, October 14, 1999 6:28 PM >>Subject: Re: Issue 2872 need to define type of identifier >> >> >>>I believe the best solution here is to have an a Trait which identifies >>>the "type" of a person. It would appear that there is no simple HL7 >>>Trait that corresponds to this. Is this, in fact, the case? If so, we >> >>HL7 has no trait or PID element for this per se, although the RIM has >>different subtypes of person which are attributed differently. This is why >>I think the type is really a role or a profile type, rather than an ID type >>(even >>though some systems have for whatever reasons chosen to concatenate them >>into IDs. In practice I like to define distinct domains for patients, >>practitioners, etc, >>and then let the correlation Mgr track the correspondence - rather than >have >>multiple >>"persons" distinquished by type within an ID. Thats not a conceptually >>valid construct, >>unless we are defining a "profile identification service (PIDS)". >> >>There must be an intention to have exactly one distinct ID value per >>real-world person. >>There could be multiple profiles as long as they are consistent >> >>>should add a Trait which describes this type, but we must define the >>>"domain" of validity of the type. I see no reason to break the IDL. >> >>Right, it is a discrete, finite (but has to extensible) domain of valid >>values. >> >>> >>>The issue here also is that a "person" can have multiple types. Should >>I would stress multiple concurrent roles. To say a person is of some >"type" >>then that >>precludes the ability to support multiple concurrently applicable types. >>Just as a person >>could be BOTH a patient and a practitioner, this is not specifying what >type >>of person they >>this is specifying their ROLEs - or the subtypes (plural) of person that >>they instantiate. >> >>1) Therefore one way to approach this is to define a trait called "roles". >>it designates the roles this person plays. I think it is a mor precise word >>than "type" for this discussion. "Type" is a hopelessly overloaded term. >> >>2) Another is to assign, for each trait, the roles (plural) for which it >>applies as an attribute. For example, >>the family name and given name components are attributes of the (base >class) >>Person role, >>and a "policy IDs" trait might map to a "beneficiary" role, and a medical >>specialties trait might map to >>a practitioners role. >> >> >>I see four possible models here: >> >>1- a trait that conveys the set of roles this person is known to occupy >>(doesnt affect IDL) >> >>2- multiple profiles (of different profile roles) per person in the same >>domain, wherein each person still has exactly one id in a given domain; >>(breaks the candidate typedef and requires a new argument in get_profile) >> >>3 - one composite profile per person within a domain, with traits that are >>each associated with various roles, e.g. name (which applies to person >role) >>= Joe, medical specialty (which applies to person and practitioner roles) = >>OBGyn. The RIM reflects this kind of of subtype factoring, and the Message >>Development Framework (MDF) as used for Version 3 knows how to roll-up >>subtype attributes into segments or XML attributes, loosely speaking. I >>think the PMF understnads property inheritance as well. (need extend IDL to >>record the roles supported for each trait name). >> >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein each >>domain supports exactly one role (Extend IdentifictionComponent so it can >>tell you what role the domain records) - and let the correlationMgr map >>them, or else let the client have the responsiblity to not log a >>practitioner profile into a purely-patient domain. The PIDS you connect to >>must be a CorrelationMgr to have knowledge of the different roles each of >>its persons occupies, but it would not know about "multiple profiles per >>person" as it is now defined. Note, however, that to say that it receives >>profiles of various roles is NOT the same as saying it has exactly one >>source domain per role. This is messy because it forces multi-domin >>semantics into the discussion of roles. >> >>Observations (not as in COAS): >>- the semantics of 1 and 2 are supported by 3, and 4; >>- the multiple profiles 2 can be derived from 3 but not 4 >>- 3 and 4 are not mutually exclusive. >>- all of these break the adopted IDL; 2 does not. >> >>Note to any implementors trying to decide which of these breaks your >>product: >>- Regardless of the approach taken, it is always valid for an MPI >>implementation to allocate IDs out of the same "integer-generating >sequence" >>for use in different domains. >> >> >>How do I decide? >>=================== >>I like 3 best because it has the richest semantics, is isomorphic with >HL7 - >>even gives HL7 a good reason to use the "identifier type" in their >>ExternalIDs struct, but functioning as a "profile type". 3 could also >>actually be turn-the-crank-derived from the RIM - all person attributes and >>person-subtype attributes would be defined as traits. We could even >define >>a compliance point by referencing a RIM version - and backwards >>compatibility just happens. Gorgeous V3 interoperablity without >>information loss in either direction. >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher >>absolute benefit for an extension-only IDL modification >> >>>Jon Farmer writes: >>> > HL7's person IDs consist of >>> > >>> > Assigning authority + the "type" of identifier + the id >>> > itself>. >>> > >>> > PIDS QualifiedPersonIDs has >>> > >>> > DomainName + PersonId >>> > >>> > Santosh points out the disparity between the HL7 three-part qualified >>IDs (a >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree >>we >>> > need to rectify the difference, however, I would not add "type" to the >>PIDS >>> > QualifiedPersonId, because (by definition of an ID domain) the ID >domain >>> > itself is adequate to disambiguate the id value. >>> > >>> > I think there is a better way to resolve it. Here is my analysis. >>> > >>> > Functionally, a person id is in fact nothing more than a coded concept >>(that >>> > just needs a unique coding schema and code part) for which the concept >>is a >>> > real world person. >>> > >>> > I believe that the HL7 use fo the identifier type is a pragmatic >>necessity >>> > for disambiguating the different roles that a newly registered person >>would >>> > play, or the "type" of profile being registeed for the real-world >>person. >>> > Any vendor that uses the same internal identifer domain for all persons >>in a >>> > system (like docs and patients) naturally needed a way to note the >>"type" of >>> > person, or the type of the profile in case there could be a distinct >>patient >>> > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE >>that >>> > is commonly used as part of a primary key for profiles. >>> > >>> > Therefore I would recommend that, rather than replicate the less-formal >>HL7 >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of a >>> > PROFILE. There are two ways to do this - one that breaks the IDL and >>one >>> > that doesn't. >>> > >>> > To break the IDL we could change the definition of profile from >>> > >>> > typedef TraitSeq Profile; >>> > to >>> > struct Profile { >>> > ProfileType enum (patient, person, practitioner, whatever); >>> > ProfileTraits TraitSeq >>> > }; >>> > >>> > To keep the IDL intact we could predefine a trait called profileType. >>> > >>> > Finally, to provide for interoperationwithout requiring either party to >>> > break backward compatibility, we could stipulate as guidance (in both >>> > forums) an isomorphic transformatiion between the two, that is how to >>> > convert person IDs in either direction without info loss or without too >>much >>> > semantic abuse. >>> > >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an >>Any, >>> > that can be structured either way. Hwoever, this would introduce >>healthcare >>> > artifiacts in a way that would be totally confusing o PIDS users in >>other >>> > domains. >>> > >>> > Jon >>> > >>> >> > > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: "Jon Farmer" cc: "Jon Farmer" , "David W. Forslund" , pids-rtf2@omg.org Message-ID: <8625681D.0064AC2E.00@em-stpmta-01.mmm.com> Date: Tue, 2 Nov 1999 11:16:41 -0700 Subject: Re: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: "25!!AnLe9H2Ne93[K!! Jon - I am sorry I did not join the discussion thread as I was on vacation the past two weeks. I think Dave's suggested solution will work for the GCPR. So if we could have another trait like TypedExternalIds whose type is a sequence of QualifiedPersonId and Identifier Type (String - if we do not want to define a table of Identifiers types). I will join the conference call on November 8th to see what the consensus is on this issue. Thanks. Santosh "Jon Farmer" on 10/21/99 04:59:48 PM Please respond to "Jon Farmer" To: "Jon Farmer" "David W. Forslund" cc: pids-rtf2@omg.org (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) Subject: Re: Issue 2872 need to define type of identifier Santosh and others, I think Dave's proposal not only meets your needs, but also the "role" oriented kind of thing I was trying to force-fit into it. Here is how I would summarize the various requirements (the ones you raised and I raised) and how Dave's solution could address them. 1) in cases where an "identifier type" is NEEDED to uniquely identify the id domain, it could be concatenated by the client to construct the existing ID domain - as the client sees fit. This would keep us from contaminating the definition of an ID domain. 2) For the case in which the type is not needed in order to make the ID domain unambiguous, but the application environment still needs a way to "qualify" the ID, as Santosh descibed - we could define a Trait to carry it, or an enhanced trait like External IDs that carries the "enhanced External IDs." Maybe call it TypedExternalIDs. We need some advice or feedback here as to what that would be called. Would this approach suffice for the GCPR? I think this is most pivotal remaining issue in the whole RTF. 3) to convey the notion of roles (which is implied in some of the HL7 values for type) without mixing it up with the type, a distinct trait perhaps called roles or even relationships could be defined by local agreement. It appears these three approaches meet all our requirements without breaking the existing IDL. We might consider now whether we need to define the new traits ( 2 and 3) as "new standard traits", or just leave it up to l ocal agreement. Dave F points out that in the Party Management Facility (PMF), roles and relationships are explicit in IDL as first class objects (interfaces). Hey Dave - can the trait's ANY carry an IOR? -----Original Message----- From: Jon Farmer To: David W. Forslund Cc: pids-rtf2@omg.org Date: Thursday, October 14, 1999 8:50 PM Subject: Re: Issue 2872 need to define type of identifier > >-----Original Message----- >From: David W. Forslund >To: Jon Farmer >Cc: pids-rtf2@omg.org >Date: Thursday, October 14, 1999 6:28 PM >Subject: Re: Issue 2872 need to define type of identifier > > >>I believe the best solution here is to have an a Trait which identifies >>the "type" of a person. It would appear that there is no simple HL7 >>Trait that corresponds to this. Is this, in fact, the case? If so, we > >HL7 has no trait or PID element for this per se, although the RIM has >different subtypes of person which are attributed differently. This is why >I think the type is really a role or a profile type, rather than an ID type >(even >though some systems have for whatever reasons chosen to concatenate them >into IDs. In practice I like to define distinct domains for patients, >practitioners, etc, >and then let the correlation Mgr track the correspondence - rather than have >multiple >"persons" distinquished by type within an ID. Thats not a conceptually >valid construct, >unless we are defining a "profile identification service (PIDS)". > >There must be an intention to have exactly one distinct ID value per >real-world person. >There could be multiple profiles as long as they are consistent > >>should add a Trait which describes this type, but we must define the >>"domain" of validity of the type. I see no reason to break the IDL. > >Right, it is a discrete, finite (but has to extensible) domain of valid >values. > >> >>The issue here also is that a "person" can have multiple types. Should >I would stress multiple concurrent roles. To say a person is of some "type" >then that >precludes the ability to support multiple concurrently applicable types. >Just as a person >could be BOTH a patient and a practitioner, this is not specifying what type >of person they >this is specifying their ROLEs - or the subtypes (plural) of person that >they instantiate. > >1) Therefore one way to approach this is to define a trait called "roles". >it designates the roles this person plays. I think it is a mor precise word >than "type" for this discussion. "Type" is a hopelessly overloaded term. > >2) Another is to assign, for each trait, the roles (plural) for which it >applies as an attribute. For example, >the family name and given name components are attributes of the (base class) >Person role, >and a "policy IDs" trait might map to a "beneficiary" role, and a medical >specialties trait might map to >a practitioners role. > > >I see four possible models here: > >1- a trait that conveys the set of roles this person is known to occupy >(doesnt affect IDL) > >2- multiple profiles (of different profile roles) per person in the same >domain, wherein each person still has exactly one id in a given domain; >(breaks the candidate typedef and requires a new argument in get_profile) > >3 - one composite profile per person within a domain, with traits that are >each associated with various roles, e.g. name (which applies to person role) >= Joe, medical specialty (which applies to person and practitioner roles) = >OBGyn. The RIM reflects this kind of of subtype factoring, and the Message >Development Framework (MDF) as used for Version 3 knows how to roll-up >subtype attributes into segments or XML attributes, loosely speaking. I >think the PMF understnads property inheritance as well. (need extend IDL to >record the roles supported for each trait name). > >4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein each >domain supports exactly one role (Extend IdentifictionComponent so it can >tell you what role the domain records) - and let the correlationMgr map >them, or else let the client have the responsiblity to not log a >practitioner profile into a purely-patient domain. The PIDS you connect to >must be a CorrelationMgr to have knowledge of the different roles each of >its persons occupies, but it would not know about "multiple profiles per >person" as it is now defined. Note, however, that to say that it receives >profiles of various roles is NOT the same as saying it has exactly one >source domain per role. This is messy because it forces multi-domin >semantics into the discussion of roles. > >Observations (not as in COAS): >- the semantics of 1 and 2 are supported by 3, and 4; >- the multiple profiles 2 can be derived from 3 but not 4 >- 3 and 4 are not mutually exclusive. >- all of these break the adopted IDL; 2 does not. > >Note to any implementors trying to decide which of these breaks your >product: >- Regardless of the approach taken, it is always valid for an MPI >implementation to allocate IDs out of the same "integer-generating sequence" >for use in different domains. > > >How do I decide? >=================== >I like 3 best because it has the richest semantics, is isomorphic with HL7 - >even gives HL7 a good reason to use the "identifier type" in their >ExternalIDs struct, but functioning as a "profile type". 3 could also >actually be turn-the-crank-derived from the RIM - all person attributes and >person-subtype attributes would be defined as traits. We could even define >a compliance point by referencing a RIM version - and backwards >compatibility just happens. Gorgeous V3 interoperablity without >information loss in either direction. > >1 has an infinite benefit-to-modifications ratio, but 3 has a higher >absolute benefit for an extension-only IDL modification > >>Jon Farmer writes: >> > HL7's person IDs consist of >> > >> > Assigning authority + the "type" of identifier + the id >> > itself>. >> > >> > PIDS QualifiedPersonIDs has >> > >> > DomainName + PersonId >> > >> > Santosh points out the disparity between the HL7 three-part qualified >IDs (a >> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree >we >> > need to rectify the difference, however, I would not add "type" to the >PIDS >> > QualifiedPersonId, because (by definition of an ID domain) the ID domain >> > itself is adequate to disambiguate the id value. >> > >> > I think there is a better way to resolve it. Here is my analysis. >> > >> > Functionally, a person id is in fact nothing more than a coded concept >(that >> > just needs a unique coding schema and code part) for which the concept >is a >> > real world person. >> > >> > I believe that the HL7 use fo the identifier type is a pragmatic >necessity >> > for disambiguating the different roles that a newly registered person >would >> > play, or the "type" of profile being registeed for the real-world >person. >> > Any vendor that uses the same internal identifer domain for all persons >in a >> > system (like docs and patients) naturally needed a way to note the >"type" of >> > person, or the type of the profile in case there could be a distinct >patient >> > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE >that >> > is commonly used as part of a primary key for profiles. >> > >> > Therefore I would recommend that, rather than replicate the less-formal >HL7 >> > artifact into our IDENTIFIER, lets incorporate it as an attribute of a >> > PROFILE. There are two ways to do this - one that breaks the IDL and >one >> > that doesn't. >> > >> > To break the IDL we could change the definition of profile from >> > >> > typedef TraitSeq Profile; >> > to >> > struct Profile { >> > ProfileType enum (patient, person, practitioner, whatever); >> > ProfileTraits TraitSeq >> > }; >> > >> > To keep the IDL intact we could predefine a trait called profileType. >> > >> > Finally, to provide for interoperationwithout requiring either party to >> > break backward compatibility, we could stipulate as guidance (in both >> > forums) an isomorphic transformatiion between the two, that is how to >> > convert person IDs in either direction without info loss or without too >much >> > semantic abuse. >> > >> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an >Any, >> > that can be structured either way. Hwoever, this would introduce >healthcare >> > artifiacts in a way that would be totally confusing o PIDS users in >other >> > domains. >> > >> > Jon >> > >> > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: "Jon Farmer" cc: "PIDS RTF" Message-ID: <8625681D.00692516.00@em-stpmta-01.mmm.com> Date: Tue, 2 Nov 1999 12:05:32 -0700 Subject: Re: Fw: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ,d!!!4CLe9H%Qe9P`)!! Jon - I am sorry for the confusion. What I meant was: in a set of External IDs for a person, same domain can not assign two identifiers of the same type. So you could have a license number (Identifier type) from State1 (domain) and another license number (Identifier 's type) from State 2 (domain), but you can not have two license numbers from the same State (domain). So a set of External Ids may look like: {DomainName UT PersonId 897654 IdType License Number}, {DomainName DOD Walter Reed PersonId 12456 IdType MRN}, {DomainName Indian Health Services PersonId 34567 IdType Tribal Enrollment Number} "Jon Farmer" on 10/25/99 02:24:56 PM Please respond to "Jon Farmer" To: "PIDS RTF" cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) Subject: Fw: Issue 2872 need to define type of identifier Santosh has specified that identifier types among a set of ExternalIDs must be unique. If I understand this correctly, this means that no two of the Qualified Person IDs in a given ExternalIDs trait can have the same identifier type. I suspect that we cannot accept this assumption, since there are an arbitrarily large number of id-assigners for a given real-world person, and there is no way they coordinate wtih each other tomake sure that only one of them is "using" the SSN or the MRN. I think it's precisely this autonomy that makes correlation necessary in the first place. Santosh can you defend the uniqueness assumption? or maybe I misunderstood, in which case I probably need an example. Jon -----Original Message----- From: Jon Farmer To: Jon Farmer ; David W. Forslund Cc: pids-rtf2@omg.org Date: Thursday, October 21, 1999 7:11 PM Subject: Re: Issue 2872 need to define type of identifier >Santosh and others, > >I think Dave's proposal not only meets your needs, but also the "role" >oriented kind of thing I was trying to force-fit into it. Here is how I >would summarize the various requirements (the ones you raised and I raised) >and how Dave's solution could address them. > >1) in cases where an "identifier type" is NEEDED to uniquely identify the id >domain, it could be concatenated by the client to construct the existing ID >domain - as the client sees fit. This would keep us from contaminating the >definition of an ID domain. > >2) For the case in which the type is not needed in order to make the ID >domain unambiguous, but the application environment still needs a way to >"qualify" the ID, as Santosh descibed - we could define a Trait to carry it, >or an enhanced trait like External IDs that carries the "enhanced External >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback >here as to what that would be called. Would this approach suffice for the >GCPR? I think this is most pivotal remaining issue in the whole RTF. > >3) to convey the notion of roles (which is implied in some of the HL7 values >for type) without mixing it up with the type, a distinct trait perhaps >called roles or even relationships could be defined by local agreement. > >It appears these three approaches meet all our requirements without breaking >the existing IDL. We might consider now whether we need to define the new >traits ( 2 and 3) as "new standard traits", or just leave it up to local >agreement. > >Dave F points out that in the Party Management Facility (PMF), roles and >relationships are explicit in IDL as first class objects (interfaces). Hey >Dave - can the trait's ANY carry an IOR? > > > >-----Original Message----- >From: Jon Farmer >To: David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 14, 1999 8:50 PM >Subject: Re: Issue 2872 need to define type of identifier > > >> >>-----Original Message----- >>From: David W. Forslund >>To: Jon Farmer >>Cc: pids-rtf2@omg.org >>Date: Thursday, October 14, 1999 6:28 PM >>Subject: Re: Issue 2872 need to define type of identifier >> >> >>>I believe the best solution here is to have an a Trait which identifies >>>the "type" of a person. It would appear that there is no simple HL7 >>>Trait that corresponds to this. Is this, in fact, the case? If so, we >> >>HL7 has no trait or PID element for this per se, although the RIM has >>different subtypes of person which are attributed differently. This is why >>I think the type is really a role or a profile type, rather than an ID type >>(even >>though some systems have for whatever reasons chosen to concatenate them >>into IDs. In practice I like to define distinct domains for patients, >>practitioners, etc, >>and then let the correlation Mgr track the correspondence - rather than >have >>multiple >>"persons" distinquished by type within an ID. Thats not a conceptually >>valid construct, >>unless we are defining a "profile identification service (PIDS)". >> >>There must be an intention to have exactly one distinct ID value per >>real-world person. >>There could be multiple profiles as long as they are consistent >> >>>should add a Trait which describes this type, but we must define the >>>"domain" of validity of the type. I see no reason to break the IDL. >> >>Right, it is a discrete, finite (but has to extensible) domain of valid >>values. >> >>> >>>The issue here also is that a "person" can have multiple types. Should >>I would stress multiple concurrent roles. To say a person is of some >"type" >>then that >>precludes the ability to support multiple concurrently applicable types. >>Just as a person >>could be BOTH a patient and a practitioner, this is not specifying what >type >>of person they >>this is specifying their ROLEs - or the subtypes (plural) of person that >>they instantiate. >> >>1) Therefore one way to approach this is to define a trait called "roles". >>it designates the roles this person plays. I think it is a mor precise word >>than "type" for this discussion. "Type" is a hopelessly overloaded term. >> >>2) Another is to assign, for each trait, the roles (plural) for which it >>applies as an attribute. For example, >>the family name and given name components are attributes of the (base >class) >>Person role, >>and a "policy IDs" trait might map to a "beneficiary" role, and a medical >>specialties trait might map to >>a practitioners role. >> >> >>I see four possible models here: >> >>1- a trait that conveys the set of roles this person is known to occupy >>(doesnt affect IDL) >> >>2- multiple profiles (of different profile roles) per person in the same >>domain, wherein each person still has exactly one id in a given domain; >>(breaks the candidate typedef and requires a new argument in get_profile) >> >>3 - one composite profile per person within a domain, with traits that are >>each associated with various roles, e.g. name (which applies to person >role) >>= Joe, medical specialty (which applies to person and practitioner roles) = >>OBGyn. The RIM reflects this kind of of subtype factoring, and the Message >>Development Framework (MDF) as used for Version 3 knows how to roll-up >>subtype attributes into segments or XML attributes, loosely speaking. I >>think the PMF understnads property inheritance as well. (need extend IDL to >>record the roles supported for each trait name). >> >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein each >>domain supports exactly one role (Extend IdentifictionComponent so it can >>tell you what role the domain records) - and let the correlationMgr map >>them, or else let the client have the responsiblity to not log a >>practitioner profile into a purely-patient domain. The PIDS you connect to >>must be a CorrelationMgr to have knowledge of the different roles each of >>its persons occupies, but it would not know about "multiple profiles per >>person" as it is now defined. Note, however, that to say that it receives >>profiles of various roles is NOT the same as saying it has exactly one >>source domain per role. This is messy because it forces multi-domin >>semantics into the discussion of roles. >> >>Observations (not as in COAS): >>- the semantics of 1 and 2 are supported by 3, and 4; >>- the multiple profiles 2 can be derived from 3 but not 4 >>- 3 and 4 are not mutually exclusive. >>- all of these break the adopted IDL; 2 does not. >> >>Note to any implementors trying to decide which of these breaks your >>product: >>- Regardless of the approach taken, it is always valid for an MPI >>implementation to allocate IDs out of the same "integer-generating >sequence" >>for use in different domains. >> >> >>How do I decide? >>=================== >>I like 3 best because it has the richest semantics, is isomorphic with >HL7 - >>even gives HL7 a good reason to use the "identifier type" in their >>ExternalIDs struct, but functioning as a "profile type". 3 could also >>actually be turn-the-crank-derived from the RIM - all person attributes and >>person-subtype attributes would be defined as traits. We could even >define >>a compliance point by referencing a RIM version - and backwards >>compatibility just happens. Gorgeous V3 interoperablity without >>information loss in either direction. >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher >>absolute benefit for an extension-only IDL modification >> >>>Jon Farmer writes: >>> > HL7's person IDs consist of >>> > >>> > Assigning authority + the "type" of identifier + the id >>> > itself>. >>> > >>> > PIDS QualifiedPersonIDs has >>> > >>> > DomainName + PersonId >>> > >>> > Santosh points out the disparity between the HL7 three-part qualified >>IDs (a >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally agree >>we >>> > need to rectify the difference, however, I would not add "type" to the >>PIDS >>> > QualifiedPersonId, because (by definition of an ID domain) the ID >domain >>> > itself is adequate to disambiguate the id value. >>> > >>> > I think there is a better way to resolve it. Here is my analysis. >>> > >>> > Functionally, a person id is in fact nothing more than a coded concept >>(that >>> > just needs a unique coding schema and code part) for which the concept >>is a >>> > real world person. >>> > >>> > I believe that the HL7 use fo the identifier type is a pragmatic >>necessity >>> > for disambiguating the different roles that a newly registered person >>would >>> > play, or the "type" of profile being registeed for the real-world >>person. >>> > Any vendor that uses the same internal identifer domain for all persons >>in a >>> > system (like docs and patients) naturally needed a way to note the >>"type" of >>> > person, or the type of the profile in case there could be a distinct >>patient >>> > profile and doc profile for a given ID. It is functionlly an ATTRIBUTE >>that >>> > is commonly used as part of a primary key for profiles. >>> > >>> > Therefore I would recommend that, rather than replicate the less-formal >>HL7 >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of a >>> > PROFILE. There are two ways to do this - one that breaks the IDL and >>one >>> > that doesn't. >>> > >>> > To break the IDL we could change the definition of profile from >>> > >>> > typedef TraitSeq Profile; >>> > to >>> > struct Profile { >>> > ProfileType enum (patient, person, practitioner, whatever); >>> > ProfileTraits TraitSeq >>> > }; >>> > >>> > To keep the IDL intact we could predefine a trait called profileType. >>> > >>> > Finally, to provide for interoperationwithout requiring either party to >>> > break backward compatibility, we could stipulate as guidance (in both >>> > forums) an isomorphic transformatiion between the two, that is how to >>> > convert person IDs in either direction without info loss or without too >>much >>> > semantic abuse. >>> > >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs an >>Any, >>> > that can be structured either way. Hwoever, this would introduce >>healthcare >>> > artifiacts in a way that would be totally confusing o PIDS users in >>other >>> > domains. >>> > >>> > Jon >>> > >>> >> > > Reply-To: "Jon Farmer" From: "Jon Farmer" To: Cc: "PIDS RTF" Subject: Re: Fw: Issue 2872 need to define type of identifier Date: Tue, 2 Nov 1999 14:25:11 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *=9e9]$,e9:Vo!!f2S!! I am wondering if you should be saying "Should not" rather than "can not". What if, within a single domain (say DoD Walter Reed) John Doe was a known duplicate - having concurrently active IDs of 1234 and 5678? In this case they would be linked in the source, and I think it would be legitimate to include both in the TypedExternalIds trait - and with the same type. Can I go so far as to tweak your statement to say that "in a set of External IDs for a person, the same domain SHOULD not assign (or will typically not assign) two identifiers of the same type."? Since in the real world dupes do occur, I think we have to allow for them, and not even throw an exception. We only throw a dupe-exception (I think it's DuplicateProfileExists ) at register-time in IdMgr when the client attempts to register someone already in the domain. Also, the client could assert any number of IDs for John Doe from the same domain in the DuplicateIDs trait. Jon -----Original Message----- From: sgandhi@mmm.com To: Jon Farmer Cc: PIDS RTF Date: Tuesday, November 02, 1999 2:05 PM Subject: Re: Fw: Issue 2872 need to define type of identifier > > >Jon - I am sorry for the confusion. What I meant was: So you could have a license number (Identifier type) from State1 >(domain) and another license number (Identifier 's type) from State 2 >(domain), but you can not have two license numbers from the same State >(domain). >So a set of External Ids may look like: > >{DomainName UT >PersonId 897654 >IdType License Number}, > >{DomainName DOD Walter Reed > PersonId 12456 >IdType MRN}, > >{DomainName Indian Health Services > PersonId 34567 > IdType Tribal Enrollment Number} > > > > >"Jon Farmer" on 10/25/99 02:24:56 PM > >Please respond to "Jon Farmer" > > >To: "PIDS RTF" >cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >Subject: Fw: Issue 2872 need to define type of identifier > > > > >Santosh has specified that identifier types among a set of ExternalIDs must >be unique. If I understand this correctly, this means that no two of the >Qualified Person IDs in a given ExternalIDs trait can have the same >identifier type. I suspect that we cannot accept this assumption, since >there are an arbitrarily large number of id-assigners for a given >real-world >person, and there is no way they coordinate wtih each other tomake sure >that >only one of them is "using" the SSN or the MRN. I think it's precisely >this >autonomy that makes correlation necessary in the first place. Santosh can >you defend the uniqueness assumption? or maybe I misunderstood, in which >case I probably need an example. >Jon >-----Original Message----- >From: Jon Farmer >To: Jon Farmer ; David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 21, 1999 7:11 PM >Subject: Re: Issue 2872 need to define type of identifier > > >>Santosh and others, >> >>I think Dave's proposal not only meets your needs, but also the "role" >>oriented kind of thing I was trying to force-fit into it. Here is how I >>would summarize the various requirements (the ones you raised and I >raised) >>and how Dave's solution could address them. >> >>1) in cases where an "identifier type" is NEEDED to uniquely identify the >id >>domain, it could be concatenated by the client to construct the existing >ID >>domain - as the client sees fit. This would keep us from contaminating >the >>definition of an ID domain. >> >>2) For the case in which the type is not needed in order to make the ID >>domain unambiguous, but the application environment still needs a way to >>"qualify" the ID, as Santosh descibed - we could define a Trait to carry >it, >>or an enhanced trait like External IDs that carries the "enhanced External >>IDs." Maybe call it TypedExternalIDs. We need some advice or feedback >>here as to what that would be called. Would this approach suffice for the >>GCPR? I think this is most pivotal remaining issue in the whole RTF. >> >>3) to convey the notion of roles (which is implied in some of the HL7 >values >>for type) without mixing it up with the type, a distinct trait perhaps >>called roles or even relationships could be defined by local agreement. >> >>It appears these three approaches meet all our requirements without >breaking >>the existing IDL. We might consider now whether we need to define the >new >>traits ( 2 and 3) as "new standard traits", or just leave it up to local >>agreement. >> >>Dave F points out that in the Party Management Facility (PMF), roles and >>relationships are explicit in IDL as first class objects (interfaces). >Hey >>Dave - can the trait's ANY carry an IOR? >> >> >> >>-----Original Message----- >>From: Jon Farmer >>To: David W. Forslund >>Cc: pids-rtf2@omg.org >>Date: Thursday, October 14, 1999 8:50 PM >>Subject: Re: Issue 2872 need to define type of identifier >> >> >>> >>>-----Original Message----- >>>From: David W. Forslund >>>To: Jon Farmer >>>Cc: pids-rtf2@omg.org >>>Date: Thursday, October 14, 1999 6:28 PM >>>Subject: Re: Issue 2872 need to define type of identifier >>> >>> >>>>I believe the best solution here is to have an a Trait which identifies >>>>the "type" of a person. It would appear that there is no simple HL7 >>>>Trait that corresponds to this. Is this, in fact, the case? If so, we >>> >>>HL7 has no trait or PID element for this per se, although the RIM has >>>different subtypes of person which are attributed differently. This is >why >>>I think the type is really a role or a profile type, rather than an ID >type >>>(even >>>though some systems have for whatever reasons chosen to concatenate them >>>into IDs. In practice I like to define distinct domains for patients, >>>practitioners, etc, >>>and then let the correlation Mgr track the correspondence - rather than >>have >>>multiple >>>"persons" distinquished by type within an ID. Thats not a conceptually >>>valid construct, >>>unless we are defining a "profile identification service (PIDS)". >>> >>>There must be an intention to have exactly one distinct ID value per >>>real-world person. >>>There could be multiple profiles as long as they are consistent >>> >>>>should add a Trait which describes this type, but we must define the >>>>"domain" of validity of the type. I see no reason to break the IDL. >>> >>>Right, it is a discrete, finite (but has to extensible) domain of valid >>>values. >>> >>>> >>>>The issue here also is that a "person" can have multiple types. Should >>>I would stress multiple concurrent roles. To say a person is of some >>"type" >>>then that >>>precludes the ability to support multiple concurrently applicable types. >>>Just as a person >>>could be BOTH a patient and a practitioner, this is not specifying what >>type >>>of person they >>>this is specifying their ROLEs - or the subtypes (plural) of person that >>>they instantiate. >>> >>>1) Therefore one way to approach this is to define a trait called >"roles". >>>it designates the roles this person plays. I think it is a mor precise >word >>>than "type" for this discussion. "Type" is a hopelessly overloaded term. >>> >>>2) Another is to assign, for each trait, the roles (plural) for which it >>>applies as an attribute. For example, >>>the family name and given name components are attributes of the (base >>class) >>>Person role, >>>and a "policy IDs" trait might map to a "beneficiary" role, and a medical >>>specialties trait might map to >>>a practitioners role. >>> >>> >>>I see four possible models here: >>> >>>1- a trait that conveys the set of roles this person is known to occupy >>>(doesnt affect IDL) >>> >>>2- multiple profiles (of different profile roles) per person in the same >>>domain, wherein each person still has exactly one id in a given domain; >>>(breaks the candidate typedef and requires a new argument in get_profile) >>> >>>3 - one composite profile per person within a domain, with traits that >are >>>each associated with various roles, e.g. name (which applies to person >>role) >>>= Joe, medical specialty (which applies to person and practitioner roles) >= >>>OBGyn. The RIM reflects this kind of of subtype factoring, and the >Message >>>Development Framework (MDF) as used for Version 3 knows how to roll-up >>>subtype attributes into segments or XML attributes, loosely speaking. I >>>think the PMF understnads property inheritance as well. (need extend IDL >to >>>record the roles supported for each trait name). >>> >>>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein >each >>>domain supports exactly one role (Extend IdentifictionComponent so it can >>>tell you what role the domain records) - and let the correlationMgr map >>>them, or else let the client have the responsiblity to not log a >>>practitioner profile into a purely-patient domain. The PIDS you connect >to >>>must be a CorrelationMgr to have knowledge of the different roles each of >>>its persons occupies, but it would not know about "multiple profiles per >>>person" as it is now defined. Note, however, that to say that it >receives >>>profiles of various roles is NOT the same as saying it has exactly one >>>source domain per role. This is messy because it forces multi-domin >>>semantics into the discussion of roles. >>> >>>Observations (not as in COAS): >>>- the semantics of 1 and 2 are supported by 3, and 4; >>>- the multiple profiles 2 can be derived from 3 but not 4 >>>- 3 and 4 are not mutually exclusive. >>>- all of these break the adopted IDL; 2 does not. >>> >>>Note to any implementors trying to decide which of these breaks your >>>product: >>>- Regardless of the approach taken, it is always valid for an MPI >>>implementation to allocate IDs out of the same "integer-generating >>sequence" >>>for use in different domains. >>> >>> >>>How do I decide? >>>=================== >>>I like 3 best because it has the richest semantics, is isomorphic with >>HL7 - >>>even gives HL7 a good reason to use the "identifier type" in their >>>ExternalIDs struct, but functioning as a "profile type". 3 could also >>>actually be turn-the-crank-derived from the RIM - all person attributes >and >>>person-subtype attributes would be defined as traits. We could even >>define >>>a compliance point by referencing a RIM version - and backwards >>>compatibility just happens. Gorgeous V3 interoperablity without >>>information loss in either direction. >>> >>>1 has an infinite benefit-to-modifications ratio, but 3 has a higher >>>absolute benefit for an extension-only IDL modification >>> >>>>Jon Farmer writes: >>>> > HL7's person IDs consist of >>>> > >>>> > Assigning authority + the "type" of identifier + the >id >>>> > itself>. >>>> > >>>> > PIDS QualifiedPersonIDs has >>>> > >>>> > DomainName + PersonId >>>> > >>>> > Santosh points out the disparity between the HL7 three-part qualified >>>IDs (a >>>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >agree >>>we >>>> > need to rectify the difference, however, I would not add "type" to >the >>>PIDS >>>> > QualifiedPersonId, because (by definition of an ID domain) the ID >>domain >>>> > itself is adequate to disambiguate the id value. >>>> > >>>> > I think there is a better way to resolve it. Here is my analysis. >>>> > >>>> > Functionally, a person id is in fact nothing more than a coded >concept >>>(that >>>> > just needs a unique coding schema and code part) for which the >concept >>>is a >>>> > real world person. >>>> > >>>> > I believe that the HL7 use fo the identifier type is a pragmatic >>>necessity >>>> > for disambiguating the different roles that a newly registered person >>>would >>>> > play, or the "type" of profile being registeed for the real-world >>>person. >>>> > Any vendor that uses the same internal identifer domain for all >persons >>>in a >>>> > system (like docs and patients) naturally needed a way to note the >>>"type" of >>>> > person, or the type of the profile in case there could be a distinct >>>patient >>>> > profile and doc profile for a given ID. It is functionlly an >ATTRIBUTE >>>that >>>> > is commonly used as part of a primary key for profiles. >>>> > >>>> > Therefore I would recommend that, rather than replicate the >less-formal >>>HL7 >>>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of >a >>>> > PROFILE. There are two ways to do this - one that breaks the IDL and >>>one >>>> > that doesn't. >>>> > >>>> > To break the IDL we could change the definition of profile from >>>> > >>>> > typedef TraitSeq Profile; >>>> > to >>>> > struct Profile { >>>> > ProfileType enum (patient, person, practitioner, whatever); >>>> > ProfileTraits TraitSeq >>>> > }; >>>> > >>>> > To keep the IDL intact we could predefine a trait called profileType. >>>> > >>>> > Finally, to provide for interoperationwithout requiring either party >to >>>> > break backward compatibility, we could stipulate as guidance (in both >>>> > forums) an isomorphic transformatiion between the two, that is how to >>>> > convert person IDs in either direction without info loss or without >too >>>much >>>> > semantic abuse. >>>> > >>>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >an >>>Any, >>>> > that can be structured either way. Hwoever, this would introduce >>>healthcare >>>> > artifiacts in a way that would be totally confusing o PIDS users in >>>other >>>> > domains. >>>> > >>>> > Jon >>>> > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: "Jon Farmer" cc: "PIDS RTF" Message-ID: <8625681D.006B9E88.00@em-stpmta-01.mmm.com> Date: Tue, 2 Nov 1999 12:32:32 -0700 Subject: Re: Fw: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: "=Ce9U#5e9Q`>e9Q on 11/02/99 12:25:11 PM Please respond to "Jon Farmer" To: Santosh Gandhi/HI-HealthInfo/3M/US cc: "PIDS RTF" Subject: Re: Fw: Issue 2872 need to define type of identifier I am wondering if you should be saying "Should not" rather than "can not". What if, within a single domain (say DoD Walter Reed) John Doe was a known duplicate - having concurrently active IDs of 1234 and 5678? In this case they would be linked in the source, and I think it would be legitimate to include both in the TypedExternalIds trait - and with the same type. Can I go so far as to tweak your statement to say that "in a set of External IDs for a person, the same domain SHOULD not assign (or will typically not assign) two identifiers of the same type."? Since in the real world dupes do occur, I think we have to allow for them, and not even throw an exception. We only throw a dupe-exception (I think it's DuplicateProfileExists ) at register-time in IdMgr when the client attempts to register someone already in the domain. Also, the client could assert any number of IDs for John Doe from the same domain in the DuplicateIDs trait. Jon -----Original Message----- From: sgandhi@mmm.com To: Jon Farmer Cc: PIDS RTF Date: Tuesday, November 02, 1999 2:05 PM Subject: Re: Fw: Issue 2872 need to define type of identifier > > >Jon - I am sorry for the confusion. What I meant was: So you could have a license number (Identifier type) from State1 >(domain) and another license number (Identifier 's type) from State 2 >(domain), but you can not have two license numbers from the same State >(domain). >So a set of External Ids may look like: > >{DomainName UT >PersonId 897654 >IdType License Number}, > >{DomainName DOD Walter Reed > PersonId 12456 >IdType MRN}, > >{DomainName Indian Health Services > PersonId 34567 > IdType Tribal Enrollment Number} > > > > >"Jon Farmer" on 10/25/99 02:24:56 PM > >Please respond to "Jon Farmer" > > >To: "PIDS RTF" >cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >Subject: Fw: Issue 2872 need to define type of identifier > > > > >Santosh has specified that identifier types among a set of ExternalIDs must >be unique. If I understand this correctly, this means that no two of the >Qualified Person IDs in a given ExternalIDs trait can have the same >identifier type. I suspect that we cannot accept this assumption, since >there are an arbitrarily large number of id-assigners for a given >real-world >person, and there is no way they coordinate wtih each other tomake sure >that >only one of them is "using" the SSN or the MRN. I think it's precisely >this >autonomy that makes correlation necessary in the first place. Santosh can >you defend the uniqueness assumption? or maybe I misunderstood, in which >case I probably need an example. >Jon >-----Original Message----- >From: Jon Farmer >To: Jon Farmer ; David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 21, 1999 7:11 PM >Subject: Re: Issue 2872 need to define type of identifier > > >>Santosh and others, >> >>I think Dave's proposal not only meets your needs, but also the "role" >>oriented kind of thing I was trying to force-fit into it. Here is how I >>would summarize the various requirements (the ones you raised and I >raised) >>and how Dave's solution could address them. >> >>1) in cases where an "identifier type" is NEEDED to uniquely identify the >id >>domain, it could be concatenated by the client to construct the existing >ID >>domain - as the client sees fit. This would keep us from contaminating >the >>definition of an ID domain. >> >>2) For the case in which the type is not needed in order to make the ID >>domain unambiguous, but the application environment still needs a way to >>"qualify" the ID, as Santosh descibed - we could define a Trait to carry >it, >>or an enhanced trait like External IDs that carries the "enhanced External >>IDs." Maybe call it TypedExternalIDs. We need some advice or feedback >>here as to what that would be called. Would this approach suffice for the >>GCPR? I think this is most pivotal remaining issue in the whole RTF. >> >>3) to convey the notion of roles (which is implied in some of the HL7 >values >>for type) without mixing it up with the type, a distinct trait perhaps >>called roles or even relationships could be defined by local agreement. >> >>It appears these three approaches meet all our requirements without >breaking >>the existing IDL. We might consider now whether we need to define the >new >>traits ( 2 and 3) as "new standard traits", or just leave it up to local >>agreement. >> >>Dave F points out that in the Party Management Facility (PMF), roles and >>relationships are explicit in IDL as first class objects (interfaces). >Hey >>Dave - can the trait's ANY carry an IOR? >> >> >> >>-----Original Message----- >>From: Jon Farmer >>To: David W. Forslund >>Cc: pids-rtf2@omg.org >>Date: Thursday, October 14, 1999 8:50 PM >>Subject: Re: Issue 2872 need to define type of identifier >> >> >>> >>>-----Original Message----- >>>From: David W. Forslund >>>To: Jon Farmer >>>Cc: pids-rtf2@omg.org >>>Date: Thursday, October 14, 1999 6:28 PM >>>Subject: Re: Issue 2872 need to define type of identifier >>> >>> >>>>I believe the best solution here is to have an a Trait which identifies >>>>the "type" of a person. It would appear that there is no simple HL7 >>>>Trait that corresponds to this. Is this, in fact, the case? If so, we >>> >>>HL7 has no trait or PID element for this per se, although the RIM has >>>different subtypes of person which are attributed differently. This is >why >>>I think the type is really a role or a profile type, rather than an ID >type >>>(even >>>though some systems have for whatever reasons chosen to concatenate them >>>into IDs. In practice I like to define distinct domains for patients, >>>practitioners, etc, >>>and then let the correlation Mgr track the correspondence - rather than >>have >>>multiple >>>"persons" distinquished by type within an ID. Thats not a conceptually >>>valid construct, >>>unless we are defining a "profile identification service (PIDS)". >>> >>>There must be an intention to have exactly one distinct ID value per >>>real-world person. >>>There could be multiple profiles as long as they are consistent >>> >>>>should add a Trait which describes this type, but we must define the >>>>"domain" of validity of the type. I see no reason to break the IDL. >>> >>>Right, it is a discrete, finite (but has to extensible) domain of valid >>>values. >>> >>>> >>>>The issue here also is that a "person" can have multiple types. Should >>>I would stress multiple concurrent roles. To say a person is of some >>"type" >>>then that >>>precludes the ability to support multiple concurrently applicable types. >>>Just as a person >>>could be BOTH a patient and a practitioner, this is not specifying what >>type >>>of person they >>>this is specifying their ROLEs - or the subtypes (plural) of person that >>>they instantiate. >>> >>>1) Therefore one way to approach this is to define a trait called >"roles". >>>it designates the roles this person plays. I think it is a mor precise >word >>>than "type" for this discussion. "Type" is a hopelessly overloaded term. >>> >>>2) Another is to assign, for each trait, the roles (plural) for which it >>>applies as an attribute. For example, >>>the family name and given name components are attributes of the (base >>class) >>>Person role, >>>and a "policy IDs" trait might map to a "beneficiary" role, and a medical >>>specialties trait might map to >>>a practitioners role. >>> >>> >>>I see four possible models here: >>> >>>1- a trait that conveys the set of roles this person is known to occupy >>>(doesnt affect IDL) >>> >>>2- multiple profiles (of different profile roles) per person in the same >>>domain, wherein each person still has exactly one id in a given domain; >>>(breaks the candidate typedef and requires a new argument in get_profile) >>> >>>3 - one composite profile per person within a domain, with traits that >are >>>each associated with various roles, e.g. name (which applies to person >>role) >>>= Joe, medical specialty (which applies to person and practitioner roles) >= >>>OBGyn. The RIM reflects this kind of of subtype factoring, and the >Message >>>Development Framework (MDF) as used for Version 3 knows how to roll-up >>>subtype attributes into segments or XML attributes, loosely speaking. I >>>think the PMF understnads property inheritance as well. (need extend IDL >to >>>record the roles supported for each trait name). >>> >>>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein >each >>>domain supports exactly one role (Extend IdentifictionComponent so it can >>>tell you what role the domain records) - and let the correlationMgr map >>>them, or else let the client have the responsiblity to not log a >>>practitioner profile into a purely-patient domain. The PIDS you connect >to >>>must be a CorrelationMgr to have knowledge of the different roles each of >>>its persons occupies, but it would not know about "multiple profiles per >>>person" as it is now defined. Note, however, that to say that it >receives >>>profiles of various roles is NOT the same as saying it has exactly one >>>source domain per role. This is messy because it forces multi-domin >>>semantics into the discussion of roles. >>> >>>Observations (not as in COAS): >>>- the semantics of 1 and 2 are supported by 3, and 4; >>>- the multiple profiles 2 can be derived from 3 but not 4 >>>- 3 and 4 are not mutually exclusive. >>>- all of these break the adopted IDL; 2 does not. >>> >>>Note to any implementors trying to decide which of these breaks your >>>product: >>>- Regardless of the approach taken, it is always valid for an MPI >>>implementation to allocate IDs out of the same "integer-generating >>sequence" >>>for use in different domains. >>> >>> >>>How do I decide? >>>=================== >>>I like 3 best because it has the richest semantics, is isomorphic with >>HL7 - >>>even gives HL7 a good reason to use the "identifier type" in their >>>ExternalIDs struct, but functioning as a "profile type". 3 could also >>>actually be turn-the-crank-derived from the RIM - all person attributes >and >>>person-subtype attributes would be defined as traits. We could even >>define >>>a compliance point by referencing a RIM version - and backwards >>>compatibility just happens. Gorgeous V3 interoperablity without >>>information loss in either direction. >>> >>>1 has an infinite benefit-to-modifications ratio, but 3 has a higher >>>absolute benefit for an extension-only IDL modification >>> >>>>Jon Farmer writes: >>>> > HL7's person IDs consist of >>>> > >>>> > Assigning authority + the "type" of identifier + the >id >>>> > itself>. >>>> > >>>> > PIDS QualifiedPersonIDs has >>>> > >>>> > DomainName + PersonId >>>> > >>>> > Santosh points out the disparity between the HL7 three-part qualified >>>IDs (a >>>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >agree >>>we >>>> > need to rectify the difference, however, I would not add "type" to >the >>>PIDS >>>> > QualifiedPersonId, because (by definition of an ID domain) the ID >>domain >>>> > itself is adequate to disambiguate the id value. >>>> > >>>> > I think there is a better way to resolve it. Here is my analysis. >>>> > >>>> > Functionally, a person id is in fact nothing more than a coded >concept >>>(that >>>> > just needs a unique coding schema and code part) for which the >concept >>>is a >>>> > real world person. >>>> > >>>> > I believe that the HL7 use fo the identifier type is a pragmatic >>>necessity >>>> > for disambiguating the different roles that a newly registered person >>>would >>>> > play, or the "type" of profile being registeed for the real-world >>>person. >>>> > Any vendor that uses the same internal identifer domain for all >persons >>>in a >>>> > system (like docs and patients) naturally needed a way to note the >>>"type" of >>>> > person, or the type of the profile in case there could be a distinct >>>patient >>>> > profile and doc profile for a given ID. It is functionlly an >ATTRIBUTE >>>that >>>> > is commonly used as part of a primary key for profiles. >>>> > >>>> > Therefore I would recommend that, rather than replicate the >less-formal >>>HL7 >>>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of >a >>>> > PROFILE. There are two ways to do this - one that breaks the IDL and >>>one >>>> > that doesn't. >>>> > >>>> > To break the IDL we could change the definition of profile from >>>> > >>>> > typedef TraitSeq Profile; >>>> > to >>>> > struct Profile { >>>> > ProfileType enum (patient, person, practitioner, whatever); >>>> > ProfileTraits TraitSeq >>>> > }; >>>> > >>>> > To keep the IDL intact we could predefine a trait called profileType. >>>> > >>>> > Finally, to provide for interoperationwithout requiring either party >to >>>> > break backward compatibility, we could stipulate as guidance (in both >>>> > forums) an isomorphic transformatiion between the two, that is how to >>>> > convert person IDs in either direction without info loss or without >too >>>much >>>> > semantic abuse. >>>> > >>>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >an >>>Any, >>>> > that can be structured either way. Hwoever, this would introduce >>>healthcare >>>> > artifiacts in a way that would be totally confusing o PIDS users in >>>other >>>> > domains. >>>> > >>>> > Jo X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 Nov 1999 15:07:53 -0700 To: sgandhi@mmm.com, "Jon Farmer" From: David Forslund Subject: Re: Fw: Issue 2872 need to define type of identifier Cc: "PIDS RTF" In-Reply-To: <8625681D.00692516.00@em-stpmta-01.mmm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: J2F!!>7Fe9-=dd9Jon - I am sorry for the confusion. What I meant was: in a set of External >IDs for a person, same domain can not assign two identifiers of the same >type. So you could have a license number (Identifier type) from State1 >(domain) and another license number (Identifier 's type) from State 2 >(domain), but you can not have two license numbers from the same State >(domain). >So a set of External Ids may look like: > >{DomainName UT >PersonId 897654 >IdType License Number}, > >{DomainName DOD Walter Reed > PersonId 12456 >IdType MRN}, > >{DomainName Indian Health Services > PersonId 34567 > IdType Tribal Enrollment Number} > > > > >"Jon Farmer" on 10/25/99 02:24:56 PM > >Please respond to "Jon Farmer" > > >To: "PIDS RTF" >cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >Subject: Fw: Issue 2872 need to define type of identifier > > > > >Santosh has specified that identifier types among a set of ExternalIDs must >be unique. If I understand this correctly, this means that no two of the >Qualified Person IDs in a given ExternalIDs trait can have the same >identifier type. I suspect that we cannot accept this assumption, since >there are an arbitrarily large number of id-assigners for a given >real-world >person, and there is no way they coordinate wtih each other tomake sure >that >only one of them is "using" the SSN or the MRN. I think it's precisely >this >autonomy that makes correlation necessary in the first place. Santosh can >you defend the uniqueness assumption? or maybe I misunderstood, in which >case I probably need an example. >Jon >-----Original Message----- >From: Jon Farmer >To: Jon Farmer ; David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 21, 1999 7:11 PM >Subject: Re: Issue 2872 need to define type of identifier > > > >Santosh and others, > > > >I think Dave's proposal not only meets your needs, but also the "role" > >oriented kind of thing I was trying to force-fit into it. Here is how I > >would summarize the various requirements (the ones you raised and I >raised) > >and how Dave's solution could address them. > > > >1) in cases where an "identifier type" is NEEDED to uniquely identify the >id > >domain, it could be concatenated by the client to construct the existing >ID > >domain - as the client sees fit. This would keep us from contaminating >the > >definition of an ID domain. > > > >2) For the case in which the type is not needed in order to make the ID > >domain unambiguous, but the application environment still needs a way to > >"qualify" the ID, as Santosh descibed - we could define a Trait to carry >it, > >or an enhanced trait like External IDs that carries the "enhanced External > >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback > >here as to what that would be called. Would this approach suffice for the > >GCPR? I think this is most pivotal remaining issue in the whole RTF. > > > >3) to convey the notion of roles (which is implied in some of the HL7 >values > >for type) without mixing it up with the type, a distinct trait perhaps > >called roles or even relationships could be defined by local agreement. > > > >It appears these three approaches meet all our requirements without >breaking > >the existing IDL. We might consider now whether we need to define the >new > >traits ( 2 and 3) as "new standard traits", or just leave it up to local > >agreement. > > > >Dave F points out that in the Party Management Facility (PMF), roles and > >relationships are explicit in IDL as first class objects (interfaces). >Hey > >Dave - can the trait's ANY carry an IOR? > > > > > > > >-----Original Message----- > >From: Jon Farmer > >To: David W. Forslund > >Cc: pids-rtf2@omg.org > >Date: Thursday, October 14, 1999 8:50 PM > >Subject: Re: Issue 2872 need to define type of identifier > > > > > >> > >>-----Original Message----- > >>From: David W. Forslund > >>To: Jon Farmer > >>Cc: pids-rtf2@omg.org > >>Date: Thursday, October 14, 1999 6:28 PM > >>Subject: Re: Issue 2872 need to define type of identifier > >> > >> > >>>I believe the best solution here is to have an a Trait which identifies > >>>the "type" of a person. It would appear that there is no simple HL7 > >>>Trait that corresponds to this. Is this, in fact, the case? If so, we > >> > >>HL7 has no trait or PID element for this per se, although the RIM has > >>different subtypes of person which are attributed differently. This is >why > >>I think the type is really a role or a profile type, rather than an ID >type > >>(even > >>though some systems have for whatever reasons chosen to concatenate them > >>into IDs. In practice I like to define distinct domains for patients, > >>practitioners, etc, > >>and then let the correlation Mgr track the correspondence - rather than > >have > >>multiple > >>"persons" distinquished by type within an ID. Thats not a conceptually > >>valid construct, > >>unless we are defining a "profile identification service (PIDS)". > >> > >>There must be an intention to have exactly one distinct ID value per > >>real-world person. > >>There could be multiple profiles as long as they are consistent > >> > >>>should add a Trait which describes this type, but we must define the > >>>"domain" of validity of the type. I see no reason to break the IDL. > >> > >>Right, it is a discrete, finite (but has to extensible) domain of valid > >>values. > >> > >>> > >>>The issue here also is that a "person" can have multiple types. Should > >>I would stress multiple concurrent roles. To say a person is of some > >"type" > >>then that > >>precludes the ability to support multiple concurrently applicable types. > >>Just as a person > >>could be BOTH a patient and a practitioner, this is not specifying what > >type > >>of person they > >>this is specifying their ROLEs - or the subtypes (plural) of person that > >>they instantiate. > >> > >>1) Therefore one way to approach this is to define a trait called >"roles". > >>it designates the roles this person plays. I think it is a mor precise >word > >>than "type" for this discussion. "Type" is a hopelessly overloaded term. > >> > >>2) Another is to assign, for each trait, the roles (plural) for which it > >>applies as an attribute. For example, > >>the family name and given name components are attributes of the (base > >class) > >>Person role, > >>and a "policy IDs" trait might map to a "beneficiary" role, and a medical > >>specialties trait might map to > >>a practitioners role. > >> > >> > >>I see four possible models here: > >> > >>1- a trait that conveys the set of roles this person is known to occupy > >>(doesnt affect IDL) > >> > >>2- multiple profiles (of different profile roles) per person in the same > >>domain, wherein each person still has exactly one id in a given domain; > >>(breaks the candidate typedef and requires a new argument in get_profile) > >> > >>3 - one composite profile per person within a domain, with traits that >are > >>each associated with various roles, e.g. name (which applies to person > >role) > >>= Joe, medical specialty (which applies to person and practitioner roles) >= > >>OBGyn. The RIM reflects this kind of of subtype factoring, and the >Message > >>Development Framework (MDF) as used for Version 3 knows how to roll-up > >>subtype attributes into segments or XML attributes, loosely speaking. I > >>think the PMF understnads property inheritance as well. (need extend IDL >to > >>record the roles supported for each trait name). > >> > >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein >each > >>domain supports exactly one role (Extend IdentifictionComponent so it can > >>tell you what role the domain records) - and let the correlationMgr map > >>them, or else let the client have the responsiblity to not log a > >>practitioner profile into a purely-patient domain. The PIDS you connect >to > >>must be a CorrelationMgr to have knowledge of the different roles each of > >>its persons occupies, but it would not know about "multiple profiles per > >>person" as it is now defined. Note, however, that to say that it >receives > >>profiles of various roles is NOT the same as saying it has exactly one > >>source domain per role. This is messy because it forces multi-domin > >>semantics into the discussion of roles. > >> > >>Observations (not as in COAS): > >>- the semantics of 1 and 2 are supported by 3, and 4; > >>- the multiple profiles 2 can be derived from 3 but not 4 > >>- 3 and 4 are not mutually exclusive. > >>- all of these break the adopted IDL; 2 does not. > >> > >>Note to any implementors trying to decide which of these breaks your > >>product: > >>- Regardless of the approach taken, it is always valid for an MPI > >>implementation to allocate IDs out of the same "integer-generating > >sequence" > >>for use in different domains. > >> > >> > >>How do I decide? > >>=================== > >>I like 3 best because it has the richest semantics, is isomorphic with > >HL7 - > >>even gives HL7 a good reason to use the "identifier type" in their > >>ExternalIDs struct, but functioning as a "profile type". 3 could also > >>actually be turn-the-crank-derived from the RIM - all person attributes >and > >>person-subtype attributes would be defined as traits. We could even > >define > >>a compliance point by referencing a RIM version - and backwards > >>compatibility just happens. Gorgeous V3 interoperablity without > >>information loss in either direction. > >> > >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher > >>absolute benefit for an extension-only IDL modification > >> > >>>Jon Farmer writes: > >>> > HL7's person IDs consist of > >>> > > >>> > Assigning authority + the "type" of identifier + the >id > >>> > itself>. > >>> > > >>> > PIDS QualifiedPersonIDs has > >>> > > >>> > DomainName + PersonId > >>> > > >>> > Santosh points out the disparity between the HL7 three-part qualified > >>IDs (a > >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >agree > >>we > >>> > need to rectify the difference, however, I would not add "type" to >the > >>PIDS > >>> > QualifiedPersonId, because (by definition of an ID domain) the ID > >domain > >>> > itself is adequate to disambiguate the id value. > >>> > > >>> > I think there is a better way to resolve it. Here is my analysis. > >>> > > >>> > Functionally, a person id is in fact nothing more than a coded >concept > >>(that > >>> > just needs a unique coding schema and code part) for which the >concept > >>is a > >>> > real world person. > >>> > > >>> > I believe that the HL7 use fo the identifier type is a pragmatic > >>necessity > >>> > for disambiguating the different roles that a newly registered person > >>would > >>> > play, or the "type" of profile being registeed for the real-world > >>person. > >>> > Any vendor that uses the same internal identifer domain for all >persons > >>in a > >>> > system (like docs and patients) naturally needed a way to note the > >>"type" of > >>> > person, or the type of the profile in case there could be a distinct > >>patient > >>> > profile and doc profile for a given ID. It is functionlly an >ATTRIBUTE > >>that > >>> > is commonly used as part of a primary key for profiles. > >>> > > >>> > Therefore I would recommend that, rather than replicate the >less-formal > >>HL7 > >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of >a > >>> > PROFILE. There are two ways to do this - one that breaks the IDL and > >>one > >>> > that doesn't. > >>> > > >>> > To break the IDL we could change the definition of profile from > >>> > > >>> > typedef TraitSeq Profile; > >>> > to > >>> > struct Profile { > >>> > ProfileType enum (patient, person, practitioner, whatever); > >>> > ProfileTraits TraitSeq > >>> > }; > >>> > > >>> > To keep the IDL intact we could predefine a trait called profileType. > >>> > > >>> > Finally, to provide for interoperationwithout requiring either party >to > >>> > break backward compatibility, we could stipulate as guidance (in both > >>> > forums) an isomorphic transformatiion between the two, that is how to > >>> > convert person IDs in either direction without info loss or without >too > >>much > >>> > semantic abuse. > >>> > > >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >an > >>Any, > >>> > that can be structured either way. Hwoever, this would introduce > >>healthcare > >>> > artifiacts in a way that would be totally confusing o PIDS users in > >>other > >>> > domains. > >>> > > >>> > Jon > >>> > Reply-To: "Jon Farmer" From: "Jon Farmer" To: , "David Forslund" Cc: "PIDS RTF" Subject: Re: Fw: Issue 2872 need to define type of identifier Date: Tue, 2 Nov 1999 18:19:58 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: YkHe9lK`!!!UOd9Jj?e9 Here is the pros/cons analysis as I see it. Who can make a case to favor one over the other? pros of TypedExternalIDs: - it's explicit - HL7 people will immediately see it there and know what it maps to in the HL7 world cons - requires IDL extension (but doesn't break anything) - a PIDS that uses just ExternalIDs will not interoperate with one that uses just Typed ExternalIDs - unless we deprecate the use of ExternalIDs in favor of TypedExternalIDs pros of concatentating - no effect on adopted IDL cons of concatentating - if we do not specify whether it should be a prefix or a suffix, it will not be interoperable - the inclusion of the type IN the domain obviously changes the value of the domain. The domain will not be comparable to that of a participant that uses the same domain but without the prefix or suffix - unless they know they are to parse it out. If we include the type concatentated into the -----Original Message----- From: David Forslund To: sgandhi@mmm.com ; Jon Farmer Cc: PIDS RTF Date: Tuesday, November 02, 1999 5:13 PM Subject: Re: Fw: Issue 2872 need to define type of identifier >This could easily be handled in the QualifiedPersonId, in my opinion with a >simple namespace defined >within the DNS naming scheme. > >UT/License/897654 >DOD_Walter_Reed/MRN/12456 >IHS/TribalNo/34567 > >Dave > >At 12:05 PM 11/2/99 -0700, sgandhi@mmm.com wrote: > > >>Jon - I am sorry for the confusion. What I meant was: in a set of External >>IDs for a person, same domain can not assign two identifiers of the same >>type. So you could have a license number (Identifier type) from State1 >>(domain) and another license number (Identifier 's type) from State 2 >>(domain), but you can not have two license numbers from the same State >>(domain). >>So a set of External Ids may look like: >> >>{DomainName UT >>PersonId 897654 >>IdType License Number}, >> >>{DomainName DOD Walter Reed >> PersonId 12456 >>IdType MRN}, >> >>{DomainName Indian Health Services >> PersonId 34567 >> IdType Tribal Enrollment Number} >> >> >> >> >>"Jon Farmer" on 10/25/99 02:24:56 PM >> >>Please respond to "Jon Farmer" >> >> >>To: "PIDS RTF" >>cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >>Subject: Fw: Issue 2872 need to define type of identifier >> >> >> >> >>Santosh has specified that identifier types among a set of ExternalIDs must >>be unique. If I understand this correctly, this means that no two of the >>Qualified Person IDs in a given ExternalIDs trait can have the same >>identifier type. I suspect that we cannot accept this assumption, since >>there are an arbitrarily large number of id-assigners for a given >>real-world >>person, and there is no way they coordinate wtih each other tomake sure >>that >>only one of them is "using" the SSN or the MRN. I think it's precisely >>this >>autonomy that makes correlation necessary in the first place. Santosh can >>you defend the uniqueness assumption? or maybe I misunderstood, in which >>case I probably need an example. >>Jon >>-----Original Message----- >>From: Jon Farmer >>To: Jon Farmer ; David W. Forslund >>Cc: pids-rtf2@omg.org >>Date: Thursday, October 21, 1999 7:11 PM >>Subject: Re: Issue 2872 need to define type of identifier >> >> >> >Santosh and others, >> > >> >I think Dave's proposal not only meets your needs, but also the "role" >> >oriented kind of thing I was trying to force-fit into it. Here is how I >> >would summarize the various requirements (the ones you raised and I >>raised) >> >and how Dave's solution could address them. >> > >> >1) in cases where an "identifier type" is NEEDED to uniquely identify the >>id >> >domain, it could be concatenated by the client to construct the existing >>ID >> >domain - as the client sees fit. This would keep us from contaminating >>the >> >definition of an ID domain. >> > >> >2) For the case in which the type is not needed in order to make the ID >> >domain unambiguous, but the application environment still needs a way to >> >"qualify" the ID, as Santosh descibed - we could define a Trait to carry >>it, >> >or an enhanced trait like External IDs that carries the "enhanced External >> >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback >> >here as to what that would be called. Would this approach suffice for the >> >GCPR? I think this is most pivotal remaining issue in the whole RTF. >> > >> >3) to convey the notion of roles (which is implied in some of the HL7 >>values >> >for type) without mixing it up with the type, a distinct trait perhaps >> >called roles or even relationships could be defined by local agreement. >> > >> >It appears these three approaches meet all our requirements without >>breaking >> >the existing IDL. We might consider now whether we need to define the >>new >> >traits ( 2 and 3) as "new standard traits", or just leave it up to local >> >agreement. >> > >> >Dave F points out that in the Party Management Facility (PMF), roles and >> >relationships are explicit in IDL as first class objects (interfaces). >>Hey >> >Dave - can the trait's ANY carry an IOR? >> > >> > >> > >> >-----Original Message----- >> >From: Jon Farmer >> >To: David W. Forslund >> >Cc: pids-rtf2@omg.org >> >Date: Thursday, October 14, 1999 8:50 PM >> >Subject: Re: Issue 2872 need to define type of identifier >> > >> > >> >> >> >>-----Original Message----- >> >>From: David W. Forslund >> >>To: Jon Farmer >> >>Cc: pids-rtf2@omg.org >> >>Date: Thursday, October 14, 1999 6:28 PM >> >>Subject: Re: Issue 2872 need to define type of identifier >> >> >> >> >> >>>I believe the best solution here is to have an a Trait which identifies >> >>>the "type" of a person. It would appear that there is no simple HL7 >> >>>Trait that corresponds to this. Is this, in fact, the case? If so, we >> >> >> >>HL7 has no trait or PID element for this per se, although the RIM has >> >>different subtypes of person which are attributed differently. This is >>why >> >>I think the type is really a role or a profile type, rather than an ID >>type >> >>(even >> >>though some systems have for whatever reasons chosen to concatenate them >> >>into IDs. In practice I like to define distinct domains for patients, >> >>practitioners, etc, >> >>and then let the correlation Mgr track the correspondence - rather than >> >have >> >>multiple >> >>"persons" distinquished by type within an ID. Thats not a conceptually >> >>valid construct, >> >>unless we are defining a "profile identification service (PIDS)". >> >> >> >>There must be an intention to have exactly one distinct ID value per >> >>real-world person. >> >>There could be multiple profiles as long as they are consistent >> >> >> >>>should add a Trait which describes this type, but we must define the >> >>>"domain" of validity of the type. I see no reason to break the IDL. >> >> >> >>Right, it is a discrete, finite (but has to extensible) domain of valid >> >>values. >> >> >> >>> >> >>>The issue here also is that a "person" can have multiple types. Should >> >>I would stress multiple concurrent roles. To say a person is of some >> >"type" >> >>then that >> >>precludes the ability to support multiple concurrently applicable types. >> >>Just as a person >> >>could be BOTH a patient and a practitioner, this is not specifying what >> >type >> >>of person they >> >>this is specifying their ROLEs - or the subtypes (plural) of person that >> >>they instantiate. >> >> >> >>1) Therefore one way to approach this is to define a trait called >>"roles". >> >>it designates the roles this person plays. I think it is a mor precise >>word >> >>than "type" for this discussion. "Type" is a hopelessly overloaded term. >> >> >> >>2) Another is to assign, for each trait, the roles (plural) for which it >> >>applies as an attribute. For example, >> >>the family name and given name components are attributes of the (base >> >class) >> >>Person role, >> >>and a "policy IDs" trait might map to a "beneficiary" role, and a medical >> >>specialties trait might map to >> >>a practitioners role. >> >> >> >> >> >>I see four possible models here: >> >> >> >>1- a trait that conveys the set of roles this person is known to occupy >> >>(doesnt affect IDL) >> >> >> >>2- multiple profiles (of different profile roles) per person in the same >> >>domain, wherein each person still has exactly one id in a given domain; >> >>(breaks the candidate typedef and requires a new argument in get_profile) >> >> >> >>3 - one composite profile per person within a domain, with traits that >>are >> >>each associated with various roles, e.g. name (which applies to person >> >role) >> >>= Joe, medical specialty (which applies to person and practitioner roles) >>= >> >>OBGyn. The RIM reflects this kind of of subtype factoring, and the >>Message >> >>Development Framework (MDF) as used for Version 3 knows how to roll-up >> >>subtype attributes into segments or XML attributes, loosely speaking. I >> >>think the PMF understnads property inheritance as well. (need extend IDL >>to >> >>record the roles supported for each trait name). >> >> >> >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein >>each >> >>domain supports exactly one role (Extend IdentifictionComponent so it can >> >>tell you what role the domain records) - and let the correlationMgr map >> >>them, or else let the client have the responsiblity to not log a >> >>practitioner profile into a purely-patient domain. The PIDS you connect >>to >> >>must be a CorrelationMgr to have knowledge of the different roles each of >> >>its persons occupies, but it would not know about "multiple profiles per >> >>person" as it is now defined. Note, however, that to say that it >>receives >> >>profiles of various roles is NOT the same as saying it has exactly one >> >>source domain per role. This is messy because it forces multi-domin >> >>semantics into the discussion of roles. >> >> >> >>Observations (not as in COAS): >> >>- the semantics of 1 and 2 are supported by 3, and 4; >> >>- the multiple profiles 2 can be derived from 3 but not 4 >> >>- 3 and 4 are not mutually exclusive. >> >>- all of these break the adopted IDL; 2 does not. >> >> >> >>Note to any implementors trying to decide which of these breaks your >> >>product: >> >>- Regardless of the approach taken, it is always valid for an MPI >> >>implementation to allocate IDs out of the same "integer-generating >> >sequence" >> >>for use in different domains. >> >> >> >> >> >>How do I decide? >> >>=================== >> >>I like 3 best because it has the richest semantics, is isomorphic with >> >HL7 - >> >>even gives HL7 a good reason to use the "identifier type" in their >> >>ExternalIDs struct, but functioning as a "profile type". 3 could also >> >>actually be turn-the-crank-derived from the RIM - all person attributes >>and >> >>person-subtype attributes would be defined as traits. We could even >> >define >> >>a compliance point by referencing a RIM version - and backwards >> >>compatibility just happens. Gorgeous V3 interoperablity without >> >>information loss in either direction. >> >> >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher >> >>absolute benefit for an extension-only IDL modification >> >> >> >>>Jon Farmer writes: >> >>> > HL7's person IDs consist of >> >>> > >> >>> > Assigning authority + the "type" of identifier + the >>id >> >>> > itself>. >> >>> > >> >>> > PIDS QualifiedPersonIDs has >> >>> > >> >>> > DomainName + PersonId >> >>> > >> >>> > Santosh points out the disparity between the HL7 three-part qualified >> >>IDs (a >> >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >>agree >> >>we >> >>> > need to rectify the difference, however, I would not add "type" to >>the >> >>PIDS >> >>> > QualifiedPersonId, because (by definition of an ID domain) the ID >> >domain >> >>> > itself is adequate to disambiguate the id value. >> >>> > >> >>> > I think there is a better way to resolve it. Here is my analysis. >> >>> > >> >>> > Functionally, a person id is in fact nothing more than a coded >>concept >> >>(that >> >>> > just needs a unique coding schema and code part) for which the >>concept >> >>is a >> >>> > real world person. >> >>> > >> >>> > I believe that the HL7 use fo the identifier type is a pragmatic >> >>necessity >> >>> > for disambiguating the different roles that a newly registered person >> >>would >> >>> > play, or the "type" of profile being registeed for the real-world >> >>person. >> >>> > Any vendor that uses the same internal identifer domain for all >>persons >> >>in a >> >>> > system (like docs and patients) naturally needed a way to note the >> >>"type" of >> >>> > person, or the type of the profile in case there could be a distinct >> >>patient >> >>> > profile and doc profile for a given ID. It is functionlly an >>ATTRIBUTE >> >>that >> >>> > is commonly used as part of a primary key for profiles. >> >>> > >> >>> > Therefore I would recommend that, rather than replicate the >>less-formal >> >>HL7 >> >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of >>a >> >>> > PROFILE. There are two ways to do this - one that breaks the IDL and >> >>one >> >>> > that doesn't. >> >>> > >> >>> > To break the IDL we could change the definition of profile from >> >>> > >> >>> > typedef TraitSeq Profile; >> >>> > to >> >>> > struct Profile { >> >>> > ProfileType enum (patient, person, practitioner, whatever); >> >>> > ProfileTraits TraitSeq >> >>> > }; >> >>> > >> >>> > To keep the IDL intact we could predefine a trait called profileType. >> >>> > >> >>> > Finally, to provide for interoperationwithout requiring either party >>to >> >>> > break backward compatibility, we could stipulate as guidance (in both >> >>> > forums) an isomorphic transformatiion between the two, that is how to >> >>> > convert person IDs in either direction without info loss or without >>too >> >>much >> >>> > semantic abuse. >> >>> > >> >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >>an >> >>Any, >> >>> > that can be structured either way. Hwoever, this would introduce >> >>healthcare >> >>> > artifiacts in a way that would be totally confusing o PIDS users in >> >>other >> >>> > domains. >> >>> > >> >>> > Jon >> >>> > From: "David W. Forslund" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Tue, 2 Nov 1999 17:09:20 -0700 (MST) To: "Jon Farmer" Cc: , "PIDS RTF" Subject: Re: Fw: Issue 2872 need to define type of identifier In-Reply-To: <001001bf2588$c8c3d340$4e1e85cd@JGFNT.toledolink.com> References: <001001bf2588$c8c3d340$4e1e85cd@JGFNT.toledolink.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14367.31865.796703.955428@gray.acl.lanl.gov> Reply-To: "David W. Forslund" Content-Type: text/plain; charset=us-ascii X-UIDL: n$P!!<=!e9B/D!!:DP!! Jon Farmer writes: > Here is the pros/cons analysis as I see it. Who can make a case to favor > one over the other? > > pros of TypedExternalIDs: > - it's explicit - HL7 people will immediately see it there and know what it > maps to in the HL7 world > cons > - requires IDL extension (but doesn't break anything) > - a PIDS that uses just ExternalIDs will not interoperate with one that uses > just Typed ExternalIDs - unless we deprecate the use of ExternalIDs in favor > of TypedExternalIDs > > > pros of concatentating > - no effect on adopted IDL > cons of concatentating > - if we do not specify whether it should be a prefix or a suffix, it will > not be interoperable > - the inclusion of the type IN the domain obviously changes the value of the > domain. The domain will not be comparable to that of a participant that > uses the same domain but without the prefix or suffix - unless they know > they are to parse it out. > What I described below won't break anything and should be immediately understandable by HL7. Compare the way HL7 types are included in the ConceptCodes in COAS to see how it could be done. It might be good to add some text to the document described a procedure (or policy?) for creating ExternalIDs, to minimize ambiguities, although within a domain people are free to do whatever they want, I claim and it shouldn't break CorrelationMgr's or anything else. It is just another trait. Dave > If we include the type concatentated into the > -----Original Message----- > From: David Forslund > To: sgandhi@mmm.com ; Jon Farmer > Cc: PIDS RTF > Date: Tuesday, November 02, 1999 5:13 PM > Subject: Re: Fw: Issue 2872 need to define type of identifier > > > >This could easily be handled in the QualifiedPersonId, in my opinion with a > >simple namespace defined > >within the DNS naming scheme. > > > >UT/License/897654 > >DOD_Walter_Reed/MRN/12456 > >IHS/TribalNo/34567 > > > >Dave > > > >At 12:05 PM 11/2/99 -0700, sgandhi@mmm.com wrote: > > > > > >>Jon - I am sorry for the confusion. What I meant was: in a set of External > >>IDs for a person, same domain can not assign two identifiers of the same > >>type. So you could have a license number (Identifier type) from State1 > >>(domain) and another license number (Identifier 's type) from State 2 > >>(domain), but you can not have two license numbers from the same State > >>(domain). > >>So a set of External Ids may look like: > >> > >>{DomainName UT > >>PersonId 897654 > >>IdType License Number}, > >> > >>{DomainName DOD Walter Reed > >> PersonId 12456 > >>IdType MRN}, > >> > >>{DomainName Indian Health Services > >> PersonId 34567 > >> IdType Tribal Enrollment Number} > >> > >> > >> > >> > >>"Jon Farmer" on 10/25/99 02:24:56 PM > >> > >>Please respond to "Jon Farmer" > >> > >> > >>To: "PIDS RTF" > >>cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > >>Subject: Fw: Issue 2872 need to define type of identifier > >> > >> > >> > >> > >>Santosh has specified that identifier types among a set of ExternalIDs > must > >>be unique. If I understand this correctly, this means that no two of the > >>Qualified Person IDs in a given ExternalIDs trait can have the same > >>identifier type. I suspect that we cannot accept this assumption, since > >>there are an arbitrarily large number of id-assigners for a given > >>real-world > >>person, and there is no way they coordinate wtih each other tomake sure > >>that > >>only one of them is "using" the SSN or the MRN. I think it's precisely > >>this > >>autonomy that makes correlation necessary in the first place. Santosh can > >>you defend the uniqueness assumption? or maybe I misunderstood, in which > >>case I probably need an example. > >>Jon > >>-----Original Message----- > >>From: Jon Farmer > >>To: Jon Farmer ; David W. Forslund > >>Cc: pids-rtf2@omg.org > >>Date: Thursday, October 21, 1999 7:11 PM > >>Subject: Re: Issue 2872 need to define type of identifier > >> > >> > >> >Santosh and others, > >> > > >> >I think Dave's proposal not only meets your needs, but also the "role" > >> >oriented kind of thing I was trying to force-fit into it. Here is how I > >> >would summarize the various requirements (the ones you raised and I > >>raised) > >> >and how Dave's solution could address them. > >> > > >> >1) in cases where an "identifier type" is NEEDED to uniquely identify > the > >>id > >> >domain, it could be concatenated by the client to construct the existing > >>ID > >> >domain - as the client sees fit. This would keep us from contaminating > >>the > >> >definition of an ID domain. > >> > > >> >2) For the case in which the type is not needed in order to make the ID > >> >domain unambiguous, but the application environment still needs a way to > >> >"qualify" the ID, as Santosh descibed - we could define a Trait to carry > >>it, > >> >or an enhanced trait like External IDs that carries the "enhanced > External > >> >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback > >> >here as to what that would be called. Would this approach suffice for > the > >> >GCPR? I think this is most pivotal remaining issue in the whole RTF. > >> > > >> >3) to convey the notion of roles (which is implied in some of the HL7 > >>values > >> >for type) without mixing it up with the type, a distinct trait perhaps > >> >called roles or even relationships could be defined by local agreement. > >> > > >> >It appears these three approaches meet all our requirements without > >>breaking > >> >the existing IDL. We might consider now whether we need to define the > >>new > >> >traits ( 2 and 3) as "new standard traits", or just leave it up to local > >> >agreement. > >> > > >> >Dave F points out that in the Party Management Facility (PMF), roles and > >> >relationships are explicit in IDL as first class objects (interfaces). > >>Hey > >> >Dave - can the trait's ANY carry an IOR? > >> > > >> > > >> > > >> >-----Original Message----- > >> >From: Jon Farmer > >> >To: David W. Forslund > >> >Cc: pids-rtf2@omg.org > >> >Date: Thursday, October 14, 1999 8:50 PM > >> >Subject: Re: Issue 2872 need to define type of identifier > >> > > >> > > >> >> > >> >>-----Original Message----- > >> >>From: David W. Forslund > >> >>To: Jon Farmer > >> >>Cc: pids-rtf2@omg.org > >> >>Date: Thursday, October 14, 1999 6:28 PM > >> >>Subject: Re: Issue 2872 need to define type of identifier > >> >> > >> >> > >> >>>I believe the best solution here is to have an a Trait which > identifies > >> >>>the "type" of a person. It would appear that there is no simple HL7 > >> >>>Trait that corresponds to this. Is this, in fact, the case? If so, we > >> >> > >> >>HL7 has no trait or PID element for this per se, although the RIM has > >> >>different subtypes of person which are attributed differently. This is > >>why > >> >>I think the type is really a role or a profile type, rather than an ID > >>type > >> >>(even > >> >>though some systems have for whatever reasons chosen to concatenate > them > >> >>into IDs. In practice I like to define distinct domains for patients, > >> >>practitioners, etc, > >> >>and then let the correlation Mgr track the correspondence - rather than > >> >have > >> >>multiple > >> >>"persons" distinquished by type within an ID. Thats not a conceptually > >> >>valid construct, > >> >>unless we are defining a "profile identification service (PIDS)". > >> >> > >> >>There must be an intention to have exactly one distinct ID value per > >> >>real-world person. > >> >>There could be multiple profiles as long as they are consistent > >> >> > >> >>>should add a Trait which describes this type, but we must define the > >> >>>"domain" of validity of the type. I see no reason to break the IDL. > >> >> > >> >>Right, it is a discrete, finite (but has to extensible) domain of valid > >> >>values. > >> >> > >> >>> > >> >>>The issue here also is that a "person" can have multiple types. Should > >> >>I would stress multiple concurrent roles. To say a person is of some > >> >"type" > >> >>then that > >> >>precludes the ability to support multiple concurrently applicable > types. > >> >>Just as a person > >> >>could be BOTH a patient and a practitioner, this is not specifying what > >> >type > >> >>of person they > >> >>this is specifying their ROLEs - or the subtypes (plural) of person > that > >> >>they instantiate. > >> >> > >> >>1) Therefore one way to approach this is to define a trait called > >>"roles". > >> >>it designates the roles this person plays. I think it is a mor precise > >>word > >> >>than "type" for this discussion. "Type" is a hopelessly overloaded > term. > >> >> > >> >>2) Another is to assign, for each trait, the roles (plural) for which > it > >> >>applies as an attribute. For example, > >> >>the family name and given name components are attributes of the (base > >> >class) > >> >>Person role, > >> >>and a "policy IDs" trait might map to a "beneficiary" role, and a > medical > >> >>specialties trait might map to > >> >>a practitioners role. > >> >> > >> >> > >> >>I see four possible models here: > >> >> > >> >>1- a trait that conveys the set of roles this person is known to occupy > >> >>(doesnt affect IDL) > >> >> > >> >>2- multiple profiles (of different profile roles) per person in the > same > >> >>domain, wherein each person still has exactly one id in a given domain; > >> >>(breaks the candidate typedef and requires a new argument in > get_profile) > >> >> > >> >>3 - one composite profile per person within a domain, with traits that > >>are > >> >>each associated with various roles, e.g. name (which applies to person > >> >role) > >> >>= Joe, medical specialty (which applies to person and practitioner > roles) > >>= > >> >>OBGyn. The RIM reflects this kind of of subtype factoring, and the > >>Message > >> >>Development Framework (MDF) as used for Version 3 knows how to roll-up > >> >>subtype attributes into segments or XML attributes, loosely speaking. > I > >> >>think the PMF understnads property inheritance as well. (need extend > IDL > >>to > >> >>record the roles supported for each trait name). > >> >> > >> >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein > >>each > >> >>domain supports exactly one role (Extend IdentifictionComponent so it > can > >> >>tell you what role the domain records) - and let the correlationMgr map > >> >>them, or else let the client have the responsiblity to not log a > >> >>practitioner profile into a purely-patient domain. The PIDS you > connect > >>to > >> >>must be a CorrelationMgr to have knowledge of the different roles each > of > >> >>its persons occupies, but it would not know about "multiple profiles > per > >> >>person" as it is now defined. Note, however, that to say that it > >>receives > >> >>profiles of various roles is NOT the same as saying it has exactly one > >> >>source domain per role. This is messy because it forces multi-domin > >> >>semantics into the discussion of roles. > >> >> > >> >>Observations (not as in COAS): > >> >>- the semantics of 1 and 2 are supported by 3, and 4; > >> >>- the multiple profiles 2 can be derived from 3 but not 4 > >> >>- 3 and 4 are not mutually exclusive. > >> >>- all of these break the adopted IDL; 2 does not. > >> >> > >> >>Note to any implementors trying to decide which of these breaks your > >> >>product: > >> >>- Regardless of the approach taken, it is always valid for an MPI > >> >>implementation to allocate IDs out of the same "integer-generating > >> >sequence" > >> >>for use in different domains. > >> >> > >> >> > >> >>How do I decide? > >> >>=================== > >> >>I like 3 best because it has the richest semantics, is isomorphic with > >> >HL7 - > >> >>even gives HL7 a good reason to use the "identifier type" in their > >> >>ExternalIDs struct, but functioning as a "profile type". 3 could also > >> >>actually be turn-the-crank-derived from the RIM - all person attributes > >>and > >> >>person-subtype attributes would be defined as traits. We could even > >> >define > >> >>a compliance point by referencing a RIM version - and backwards > >> >>compatibility just happens. Gorgeous V3 interoperablity without > >> >>information loss in either direction. > >> >> > >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher > >> >>absolute benefit for an extension-only IDL modification > >> >> > >> >>>Jon Farmer writes: > >> >>> > HL7's person IDs consist of > >> >>> > > >> >>> > Assigning authority + the "type" of identifier + > the > >>id > >> >>> > itself>. > >> >>> > > >> >>> > PIDS QualifiedPersonIDs has > >> >>> > > >> >>> > DomainName + PersonId > >> >>> > > >> >>> > Santosh points out the disparity between the HL7 three-part > qualified > >> >>IDs (a > >> >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally > >>agree > >> >>we > >> >>> > need to rectify the difference, however, I would not add "type" to > >>the > >> >>PIDS > >> >>> > QualifiedPersonId, because (by definition of an ID domain) the ID > >> >domain > >> >>> > itself is adequate to disambiguate the id value. > >> >>> > > >> >>> > I think there is a better way to resolve it. Here is my analysis. > >> >>> > > >> >>> > Functionally, a person id is in fact nothing more than a coded > >>concept > >> >>(that > >> >>> > just needs a unique coding schema and code part) for which the > >>concept > >> >>is a > >> >>> > real world person. > >> >>> > > >> >>> > I believe that the HL7 use fo the identifier type is a pragmatic > >> >>necessity > >> >>> > for disambiguating the different roles that a newly registered > person > >> >>would > >> >>> > play, or the "type" of profile being registeed for the real-world > >> >>person. > >> >>> > Any vendor that uses the same internal identifer domain for all > >>persons > >> >>in a > >> >>> > system (like docs and patients) naturally needed a way to note the > >> >>"type" of > >> >>> > person, or the type of the profile in case there could be a > distinct > >> >>patient > >> >>> > profile and doc profile for a given ID. It is functionlly an > >>ATTRIBUTE > >> >>that > >> >>> > is commonly used as part of a primary key for profiles. > >> >>> > > >> >>> > Therefore I would recommend that, rather than replicate the > >>less-formal > >> >>HL7 > >> >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute > of > >>a > >> >>> > PROFILE. There are two ways to do this - one that breaks the IDL > and > >> >>one > >> >>> > that doesn't. > >> >>> > > >> >>> > To break the IDL we could change the definition of profile from > >> >>> > > >> >>> > typedef TraitSeq Profile; > >> >>> > to > >> >>> > struct Profile { > >> >>> > ProfileType enum (patient, person, practitioner, whatever); > >> >>> > ProfileTraits TraitSeq > >> >>> > }; > >> >>> > > >> >>> > To keep the IDL intact we could predefine a trait called > profileType. > >> >>> > > >> >>> > Finally, to provide for interoperationwithout requiring either > party > >>to > >> >>> > break backward compatibility, we could stipulate as guidance (in > both > >> >>> > forums) an isomorphic transformatiion between the two, that is how > to > >> >>> > convert person IDs in either direction without info loss or without > >>too > >> >>much > >> >>> > semantic abuse. > >> >>> > > >> >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs > >>an > >> >>Any, > >> >>> > that can be structured either way. Hwoever, this would introduce > >> >>healthcare > >> >>> > artifiacts in a way that would be totally confusing o PIDS users in > >> >>other > >> >>> > domains. > >> >>> > > >> >>> > Jon Reply-To: "Jon Farmer" From: "Jon Farmer" To: "David W. Forslund" Cc: , "PIDS RTF" Subject: Re: Fw: Issue 2872 need to define type of identifier Date: Tue, 2 Nov 1999 21:40:22 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: f#*!!S4E!!^Hod9M5Ce9 Hi Dave I was following you fine until you said "It's just another trait". Isn't your main point to do this without adding a trait? If we permit the type to be embedded in the domain, then it becomes inaccessible unless we specify how one can get to it if it's there. I twould think the type, if included, should be in the "least signifiant qualifier" position, or the position immediately qualifying the "domain proper", whether that means before it or after it in the naming system used. Jon -----Original Message----- From: David W. Forslund To: Jon Farmer Cc: sgandhi@mmm.com ; PIDS RTF Date: Tuesday, November 02, 1999 7:13 PM Subject: Re: Fw: Issue 2872 need to define type of identifier >Jon Farmer writes: > > Here is the pros/cons analysis as I see it. Who can make a case > to favor > > one over the other? > > > > pros of TypedExternalIDs: > > - it's explicit - HL7 people will immediately see it there and > know what it > > maps to in the HL7 world > > cons > > - requires IDL extension (but doesn't break anything) > > - a PIDS that uses just ExternalIDs will not interoperate with one > that uses > > just Typed ExternalIDs - unless we deprecate the use of > ExternalIDs in favor > > of TypedExternalIDs > > > > > > pros of concatentating > > - no effect on adopted IDL > > cons of concatentating > > - if we do not specify whether it should be a prefix or a suffix, > it will > > not be interoperable > > - the inclusion of the type IN the domain obviously changes the > value of the > > domain. The domain will not be comparable to that of a > participant that > > uses the same domain but without the prefix or suffix - unless > they know > > they are to parse it out. > > >What I described below won't break anything and should be immediately >understandable by HL7. Compare the way HL7 types are included in the >ConceptCodes in COAS to see how it could be done. It might be good > to >add some text to the document described a procedure (or policy?) for >creating ExternalIDs, to minimize ambiguities, although within a > domain >people are free to do whatever they want, I claim and it shouldn't > break >CorrelationMgr's or anything else. It is just another trait. > >Dave > > > > If we include the type concatentated into the > > -----Original Message----- > > From: David Forslund > > To: sgandhi@mmm.com ; Jon Farmer > > Cc: PIDS RTF > > Date: Tuesday, November 02, 1999 5:13 PM > > Subject: Re: Fw: Issue 2872 need to define type of identifier > > > > > > >This could easily be handled in the QualifiedPersonId, in my > opinion with a > > >simple namespace defined > > >within the DNS naming scheme. > > > > > >UT/License/897654 > > >DOD_Walter_Reed/MRN/12456 > > >IHS/TribalNo/34567 > > > > > >Dave > > > > > >At 12:05 PM 11/2/99 -0700, sgandhi@mmm.com wrote: > > > > > > > > >>Jon - I am sorry for the confusion. What I meant was: in a set > of External > > >>IDs for a person, same domain can not assign two identifiers of > the same > > >>type. So you could have a license number (Identifier type) from > State1 > > >>(domain) and another license number (Identifier 's type) from > State 2 > > >>(domain), but you can not have two license numbers from the same > State > > >>(domain). > > >>So a set of External Ids may look like: > > >> > > >>{DomainName UT > > >>PersonId 897654 > > >>IdType License Number}, > > >> > > >>{DomainName DOD Walter Reed > > >> PersonId 12456 > > >>IdType MRN}, > > >> > > >>{DomainName Indian Health Services > > >> PersonId 34567 > > >> IdType Tribal Enrollment Number} > > >> > > >> > > >> > > >> > > >>"Jon Farmer" on 10/25/99 02:24:56 PM > > >> > > >>Please respond to "Jon Farmer" > > >> > > >> > > >>To: "PIDS RTF" > > >>cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) > > >>Subject: Fw: Issue 2872 need to define type of identifier > > >> > > >> > > >> > > >> > > >>Santosh has specified that identifier types among a set of > ExternalIDs > > must > > >>be unique. If I understand this correctly, this means that no > two of the > > >>Qualified Person IDs in a given ExternalIDs trait can have the > same > > >>identifier type. I suspect that we cannot accept this > assumption, since > > >>there are an arbitrarily large number of id-assigners for a > given > > >>real-world > > >>person, and there is no way they coordinate wtih each other > tomake sure > > >>that > > >>only one of them is "using" the SSN or the MRN. I think it's precisely > > >>this > > >>autonomy that makes correlation necessary in the first place. > Santosh can > > >>you defend the uniqueness assumption? or maybe I misunderstood, > in which > > >>case I probably need an example. > > >>Jon > > >>-----Original Message----- > > >>From: Jon Farmer > > >>To: Jon Farmer ; David W. Forslund > > > >>Cc: pids-rtf2@omg.org > > >>Date: Thursday, October 21, 1999 7:11 PM > > >>Subject: Re: Issue 2872 need to define type of identifier > > >> > > >> > > >> >Santosh and others, > > >> > > > >> >I think Dave's proposal not only meets your needs, but also > the "role" > > >> >oriented kind of thing I was trying to force-fit into it. > Here is how I > > >> >would summarize the various requirements (the ones you raised > and I > > >>raised) > > >> >and how Dave's solution could address them. > > >> > > > >> >1) in cases where an "identifier type" is NEEDED to uniquely identify > > the > > >>id > > >> >domain, it could be concatenated by the client to construct > the existing > > >>ID > > >> >domain - as the client sees fit. This would keep us from contaminating > > >>the > > >> >definition of an ID domain. > > >> > > > >> >2) For the case in which the type is not needed in order to > make the ID > > >> >domain unambiguous, but the application environment still > needs a way to > > >> >"qualify" the ID, as Santosh descibed - we could define a > Trait to carry > > >>it, > > >> >or an enhanced trait like External IDs that carries the > "enhanced > > External > > >> >IDs." Maybe call it TypedExternalIDs. We need some advice > or feedback > > >> >here as to what that would be called. Would this approach > suffice for > > the > > >> >GCPR? I think this is most pivotal remaining issue in the > whole RTF. > > >> > > > >> >3) to convey the notion of roles (which is implied in some of > the HL7 > > >>values > > >> >for type) without mixing it up with the type, a distinct trait perhaps > > >> >called roles or even relationships could be defined by local agreement. > > >> > > > >> >It appears these three approaches meet all our requirements > without > > >>breaking > > >> >the existing IDL. We might consider now whether we need to > define the > > >>new > > >> >traits ( 2 and 3) as "new standard traits", or just leave it > up to local > > >> >agreement. > > >> > > > >> >Dave F points out that in the Party Management Facility (PMF), > roles and > > >> >relationships are explicit in IDL as first class objects (interfaces). > > >>Hey > > >> >Dave - can the trait's ANY carry an IOR? > > >> > > > >> > > > >> > > > >> >-----Original Message----- > > >> >From: Jon Farmer > > >> >To: David W. Forslund > > >> >Cc: pids-rtf2@omg.org > > >> >Date: Thursday, October 14, 1999 8:50 PM > > >> >Subject: Re: Issue 2872 need to define type of identifier > > >> > > > >> > > > >> >> > > >> >>-----Original Message----- > > >> >>From: David W. Forslund > > >> >>To: Jon Farmer > > >> >>Cc: pids-rtf2@omg.org > > >> >>Date: Thursday, October 14, 1999 6:28 PM > > >> >>Subject: Re: Issue 2872 need to define type of identifier > > >> >> > > >> >> > > >> >>>I believe the best solution here is to have an a Trait which > > identifies > > >> >>>the "type" of a person. It would appear that there is no > simple HL7 > > >> >>>Trait that corresponds to this. Is this, in fact, the case? > If so, we > > >> >> > > >> >>HL7 has no trait or PID element for this per se, although the > RIM has > > >> >>different subtypes of person which are attributed > differently. This is > > >>why > > >> >>I think the type is really a role or a profile type, rather > than an ID > > >>type > > >> >>(even > > >> >>though some systems have for whatever reasons chosen to > concatenate > > them > > >> >>into IDs. In practice I like to define distinct domains for patients, > > >> >>practitioners, etc, > > >> >>and then let the correlation Mgr track the correspondence - > rather than > > >> >have > > >> >>multiple > > >> >>"persons" distinquished by type within an ID. Thats not a conceptually > > >> >>valid construct, > > >> >>unless we are defining a "profile identification service > (PIDS)". > > >> >> > > >> >>There must be an intention to have exactly one distinct ID > value per > > >> >>real-world person. > > >> >>There could be multiple profiles as long as they are > consistent > > >> >> > > >> >>>should add a Trait which describes this type, but we must > define the > > >> >>>"domain" of validity of the type. I see no reason to break > the IDL. > > >> >> > > >> >>Right, it is a discrete, finite (but has to extensible) > domain of valid > > >> >>values. > > >> >> > > >> >>> > > >> >>>The issue here also is that a "person" can have multiple > types. Should > > >> >>I would stress multiple concurrent roles. To say a person is > of some > > >> >"type" > > >> >>then that > > >> >>precludes the ability to support multiple concurrently > applicable > > types. > > >> >>Just as a person > > >> >>could be BOTH a patient and a practitioner, this is not > specifying what > > >> >type > > >> >>of person they > > >> >>this is specifying their ROLEs - or the subtypes (plural) of > person > > that > > >> >>they instantiate. > > >> >> > > >> >>1) Therefore one way to approach this is to define a trait > called > > >>"roles". > > >> >>it designates the roles this person plays. I think it is a > mor precise > > >>word > > >> >>than "type" for this discussion. "Type" is a hopelessly > overloaded > > term. > > >> >> > > >> >>2) Another is to assign, for each trait, the roles (plural) > for which > > it > > >> >>applies as an attribute. For example, > > >> >>the family name and given name components are attributes of > the (base > > >> >class) > > >> >>Person role, > > >> >>and a "policy IDs" trait might map to a "beneficiary" role, > and a > > medical > > >> >>specialties trait might map to > > >> >>a practitioners role. > > >> >> > > >> >> > > >> >>I see four possible models here: > > >> >> > > >> >>1- a trait that conveys the set of roles this person is known > to occupy > > >> >>(doesnt affect IDL) > > >> >> > > >> >>2- multiple profiles (of different profile roles) per person > in the > > same > > >> >>domain, wherein each person still has exactly one id in a > given domain; > > >> >>(breaks the candidate typedef and requires a new argument in > > get_profile) > > >> >> > > >> >>3 - one composite profile per person within a domain, with > traits that > > >>are > > >> >>each associated with various roles, e.g. name (which applies > to person > > >> >role) > > >> >>= Joe, medical specialty (which applies to person and > practitioner > > roles) > > >>= > > >> >>OBGyn. The RIM reflects this kind of of subtype factoring, > and the > > >>Message > > >> >>Development Framework (MDF) as used for Version 3 knows how > to roll-up > > >> >>subtype attributes into segments or XML attributes, loosely speaking. > > I > > >> >>think the PMF understnads property inheritance as well. (need extend > > IDL > > >>to > > >> >>record the roles supported for each trait name). > > >> >> > > >> >>4 - track role-distinct distinct profiles in SEPARATE > DOMAINS, wherein > > >>each > > >> >>domain supports exactly one role (Extend > IdentifictionComponent so it > > can > > >> >>tell you what role the domain records) - and let the > correlationMgr map > > >> >>them, or else let the client have the responsiblity to not > log a > > >> >>practitioner profile into a purely-patient domain. The PIDS > you > > connect > > >>to > > >> >>must be a CorrelationMgr to have knowledge of the different > roles each > > of > > >> >>its persons occupies, but it would not know about "multiple profiles > > per > > >> >>person" as it is now defined. Note, however, that to say > that it > > >>receives > > >> >>profiles of various roles is NOT the same as saying it has > exactly one > > >> >>source domain per role. This is messy because it forces multi-domin > > >> >>semantics into the discussion of roles. > > >> >> > > >> >>Observations (not as in COAS): > > >> >>- the semantics of 1 and 2 are supported by 3, and 4; > > >> >>- the multiple profiles 2 can be derived from 3 but not 4 > > >> >>- 3 and 4 are not mutually exclusive. > > >> >>- all of these break the adopted IDL; 2 does not. > > >> >> > > >> >>Note to any implementors trying to decide which of these > breaks your > > >> >>product: > > >> >>- Regardless of the approach taken, it is always valid for an > MPI > > >> >>implementation to allocate IDs out of the same > "integer-generating > > >> >sequence" > > >> >>for use in different domains. > > >> >> > > >> >> > > >> >>How do I decide? > > >> >>=================== > > >> >>I like 3 best because it has the richest semantics, is > isomorphic with > > >> >HL7 - > > >> >>even gives HL7 a good reason to use the "identifier type" in > their > > >> >>ExternalIDs struct, but functioning as a "profile type". 3 > could also > > >> >>actually be turn-the-crank-derived from the RIM - all person attributes > > >>and > > >> >>person-subtype attributes would be defined as traits. We > could even > > >> >define > > >> >>a compliance point by referencing a RIM version - and > backwards > > >> >>compatibility just happens. Gorgeous V3 interoperablity > without > > >> >>information loss in either direction. > > >> >> > > >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher > > >> >>absolute benefit for an extension-only IDL modification > > >> >> > > >> >>>Jon Farmer writes: > > >> >>> > HL7's person IDs consist of > > >> >>> > > > >> >>> > Assigning authority + the "type" of > identifier + > > the > > >>id > > >> >>> > itself>. > > >> >>> > > > >> >>> > PIDS QualifiedPersonIDs has > > >> >>> > > > >> >>> > DomainName + PersonId > > >> >>> > > > >> >>> > Santosh points out the disparity between the HL7 > three-part > > qualified > > >> >>IDs (a > > >> >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally > > >>agree > > >> >>we > > >> >>> > need to rectify the difference, however, I would not add > "type" to > > >>the > > >> >>PIDS > > >> >>> > QualifiedPersonId, because (by definition of an ID > domain) the ID > > >> >domain > > >> >>> > itself is adequate to disambiguate the id value. > > >> >>> > > > >> >>> > I think there is a better way to resolve it. Here is my analysis. > > >> >>> > > > >> >>> > Functionally, a person id is in fact nothing more than a > coded > > >>concept > > >> >>(that > > >> >>> > just needs a unique coding schema and code part) for > which the > > >>concept > > >> >>is a > > >> >>> > real world person. > > >> >>> > > > >> >>> > I believe that the HL7 use fo the identifier type is a pragmatic > > >> >>necessity > > >> >>> > for disambiguating the different roles that a newly > registered > > person > > >> >>would > > >> >>> > play, or the "type" of profile being registeed for the real-world > > >> >>person. > > >> >>> > Any vendor that uses the same internal identifer domain > for all > > >>persons > > >> >>in a > > >> >>> > system (like docs and patients) naturally needed a way to > note the > > >> >>"type" of > > >> >>> > person, or the type of the profile in case there could be > a > > distinct > > >> >>patient > > >> >>> > profile and doc profile for a given ID. It is > functionlly an > > >>ATTRIBUTE > > >> >>that > > >> >>> > is commonly used as part of a primary key for profiles. > > >> >>> > > > >> >>> > Therefore I would recommend that, rather than replicate > the > > >>less-formal > > >> >>HL7 > > >> >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute > > of > > >>a > > >> >>> > PROFILE. There are two ways to do this - one that breaks > the IDL > > and > > >> >>one > > >> >>> > that doesn't. > > >> >>> > > > >> >>> > To break the IDL we could change the definition of > profile from > > >> >>> > > > >> >>> > typedef TraitSeq Profile; > > >> >>> > to > > >> >>> > struct Profile { > > >> >>> > ProfileType enum (patient, person, practitioner, whatever); > > >> >>> > ProfileTraits TraitSeq > > >> >>> > }; > > >> >>> > > > >> >>> > To keep the IDL intact we could predefine a trait called > > profileType. > > >> >>> > > > >> >>> > Finally, to provide for interoperationwithout requiring > either > > party > > >>to > > >> >>> > break backward compatibility, we could stipulate as > guidance (in > > both > > >> >>> > forums) an isomorphic transformatiion between the two, > that is how > > to > > >> >>> > convert person IDs in either direction without info loss > or without > > >>too > > >> >>much > > >> >>> > semantic abuse. > > >> >>> > > > >> >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs > > >>an > > >> >>Any, > > >> >>> > that can be structured either way. Hwoever, this would introduce > > >> >>healthcare > > >> >>> > artifiacts in a way that would be totally confusing o > PIDS users in > > >> >>other > > >> >>> > domains. > > >> >>> > > > >> >>> > Jon > > >> >>> > X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 Nov 1999 21:59:48 -0700 To: pids-rtf2@omg.org From: David Forslund Subject: Fwd: Re: Fw: Issue 2872 need to define type of identifier Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: g8Ce9g?%!!!3Q!!X7H!! >Date: Tue, 02 Nov 1999 21:55:29 -0700 >To: "Jon Farmer" >From: David Forslund >Subject: Re: Fw: Issue 2872 need to define type of identifier > >At 09:40 PM 11/2/99 -0500, you wrote: >>Hi Dave >>I was following you fine until you said "It's just another trait". Isn't >>your main point to do this without adding a trait? > >It isn't a new trait, just another of what is already supported: >ExternalID= QualifiedPersonId. >The type really isn't in the domain. It is in the local name, isn't it? > >Did you look at how HL7 stuff is handled in COAS? I think this pretty >much the same. >A domain can control its name space, without any problems to other domains. > >>If we permit the type to be embedded in the domain, then it becomes >>inaccessible unless we specify how one can get to it if it's there. I >>twould think the type, if included, should be in the "least signifiant >>qualifier" position, or the position immediately qualifying the "domain >>proper", whether that means before it or after it in the naming system used. >>Jon > >I don't see why it is "inaccessible". It is just part of the ExternalId >which can be searched on >just like any other standard Trait. > >Dave > >>-----Original Message----- >>From: David W. Forslund >>To: Jon Farmer >>Cc: sgandhi@mmm.com ; PIDS RTF >>Date: Tuesday, November 02, 1999 7:13 PM >>Subject: Re: Fw: Issue 2872 need to define type of identifier >> >> >> >Jon Farmer writes: >> > > Here is the pros/cons analysis as I see it. Who can make a case to >>favor >> > > one over the other? >> > > >> > > pros of TypedExternalIDs: >> > > - it's explicit - HL7 people will immediately see it there and know what >>it >> > > maps to in the HL7 world >> > > cons >> > > - requires IDL extension (but doesn't break anything) >> > > - a PIDS that uses just ExternalIDs will not interoperate with one that >>uses >> > > just Typed ExternalIDs - unless we deprecate the use of ExternalIDs in >>favor >> > > of TypedExternalIDs >> > > >> > > >> > > pros of concatentating >> > > - no effect on adopted IDL >> > > cons of concatentating >> > > - if we do not specify whether it should be a prefix or a suffix, it >>will >> > > not be interoperable >> > > - the inclusion of the type IN the domain obviously changes the value of >>the >> > > domain. The domain will not be comparable to that of a participant that >> > > uses the same domain but without the prefix or suffix - unless they know >> > > they are to parse it out. >> > > >> >What I described below won't break anything and should be immediately >> >understandable by HL7. Compare the way HL7 types are included in the >> >ConceptCodes in COAS to see how it could be done. It might be good to >> >add some text to the document described a procedure (or policy?) for >> >creating ExternalIDs, to minimize ambiguities, although within a domain >> >people are free to do whatever they want, I claim and it shouldn't break >> >CorrelationMgr's or anything else. It is just another trait. >> > >> >Dave >> > >> > >> > > If we include the type concatentated into the >> > > -----Original Message----- >> > > From: David Forslund >> > > To: sgandhi@mmm.com ; Jon Farmer >> > > Cc: PIDS RTF >> > > Date: Tuesday, November 02, 1999 5:13 PM >> > > Subject: Re: Fw: Issue 2872 need to define type of identifier >> > > >> > > >> > > >This could easily be handled in the QualifiedPersonId, in my opinion >>with a >> > > >simple namespace defined >> > > >within the DNS naming scheme. >> > > > >> > > >UT/License/897654 >> > > >DOD_Walter_Reed/MRN/12456 >> > > >IHS/TribalNo/34567 >> > > > >> > > >Dave >> > > > >> > > >At 12:05 PM 11/2/99 -0700, sgandhi@mmm.com wrote: >> > > > >> > > > >> > > >>Jon - I am sorry for the confusion. What I meant was: in a set of >>External >> > > >>IDs for a person, same domain can not assign two identifiers of the >>same >> > > >>type. So you could have a license number (Identifier type) from State1 >> > > >>(domain) and another license number (Identifier 's type) from State 2 >> > > >>(domain), but you can not have two license numbers from the same State >> > > >>(domain). >> > > >>So a set of External Ids may look like: >> > > >> >> > > >>{DomainName UT >> > > >>PersonId 897654 >> > > >>IdType License Number}, >> > > >> >> > > >>{DomainName DOD Walter Reed >> > > >> PersonId 12456 >> > > >>IdType MRN}, >> > > >> >> > > >>{DomainName Indian Health Services >> > > >> PersonId 34567 >> > > >> IdType Tribal Enrollment Number} >> > > >> >> > > >> >> > > >> >> > > >> >> > > >>"Jon Farmer" on 10/25/99 02:24:56 PM >> > > >> >> > > >>Please respond to "Jon Farmer" >> > > >> >> > > >> >> > > >>To: "PIDS RTF" >> > > >>cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >> > > >>Subject: Fw: Issue 2872 need to define type of identifier >> > > >> >> > > >> >> > > >> >> > > >> >> > > >>Santosh has specified that identifier types among a set of ExternalIDs >> > > must >> > > >>be unique. If I understand this correctly, this means that no two of >>the >> > > >>Qualified Person IDs in a given ExternalIDs trait can have the same >> > > >>identifier type. I suspect that we cannot accept this assumption, >>since >> > > >>there are an arbitrarily large number of id-assigners for a given >> > > >>real-world >> > > >>person, and there is no way they coordinate wtih each other tomake >>sure >> > > >>that >> > > >>only one of them is "using" the SSN or the MRN. I think it's >>precisely >> > > >>this >> > > >>autonomy that makes correlation necessary in the first place. Santosh >>can >> > > >>you defend the uniqueness assumption? or maybe I misunderstood, in >>which >> > > >>case I probably need an example. >> > > >>Jon >> > > >>-----Original Message----- >> > > >>From: Jon Farmer >> > > >>To: Jon Farmer ; David W. Forslund >> > > >>Cc: pids-rtf2@omg.org >> > > >>Date: Thursday, October 21, 1999 7:11 PM >> > > >>Subject: Re: Issue 2872 need to define type of identifier >> > > >> >> > > >> >> > > >> >Santosh and others, >> > > >> > >> > > >> >I think Dave's proposal not only meets your needs, but also the >>"role" >> > > >> >oriented kind of thing I was trying to force-fit into it. Here is >>how I >> > > >> >would summarize the various requirements (the ones you raised and I >> > > >>raised) >> > > >> >and how Dave's solution could address them. >> > > >> > >> > > >> >1) in cases where an "identifier type" is NEEDED to uniquely >>identify >> > > the >> > > >>id >> > > >> >domain, it could be concatenated by the client to construct the >>existing >> > > >>ID >> > > >> >domain - as the client sees fit. This would keep us from >>contaminating >> > > >>the >> > > >> >definition of an ID domain. >> > > >> > >> > > >> >2) For the case in which the type is not needed in order to make the >>ID >> > > >> >domain unambiguous, but the application environment still needs a >>way to >> > > >> >"qualify" the ID, as Santosh descibed - we could define a Trait to >>carry >> > > >>it, >> > > >> >or an enhanced trait like External IDs that carries the "enhanced >> > > External >> > > >> >IDs." Maybe call it TypedExternalIDs. We need some advice or >>feedback >> > > >> >here as to what that would be called. Would this approach suffice >>for >> > > the >> > > >> >GCPR? I think this is most pivotal remaining issue in the whole >>RTF. >> > > >> > >> > > >> >3) to convey the notion of roles (which is implied in some of the >>HL7 >> > > >>values >> > > >> >for type) without mixing it up with the type, a distinct trait >>perhaps >> > > >> >called roles or even relationships could be defined by local >>agreement. >> > > >> > >> > > >> >It appears these three approaches meet all our requirements without >> > > >>breaking >> > > >> >the existing IDL. We might consider now whether we need to define >>the >> > > >>new >> > > >> >traits ( 2 and 3) as "new standard traits", or just leave it up to >>local >> > > >> >agreement. >> > > >> > >> > > >> >Dave F points out that in the Party Management Facility (PMF), roles >>and >> > > >> >relationships are explicit in IDL as first class objects >>(interfaces). >> > > >>Hey >> > > >> >Dave - can the trait's ANY carry an IOR? >> > > >> > >> > > >> > >> > > >> > >> > > >> >-----Original Message----- >> > > >> >From: Jon Farmer >> > > >> >To: David W. Forslund >> > > >> >Cc: pids-rtf2@omg.org >> > > >> >Date: Thursday, October 14, 1999 8:50 PM >> > > >> >Subject: Re: Issue 2872 need to define type of identifier >> > > >> > >> > > >> > >> > > >> >> >> > > >> >>-----Original Message----- >> > > >> >>From: David W. Forslund >> > > >> >>To: Jon Farmer >> > > >> >>Cc: pids-rtf2@omg.org >> > > >> >>Date: Thursday, October 14, 1999 6:28 PM >> > > >> >>Subject: Re: Issue 2872 need to define type of identifier >> > > >> >> >> > > >> >> >> > > >> >>>I believe the best solution here is to have an a Trait which >> > > identifies >> > > >> >>>the "type" of a person. It would appear that there is no simple >>HL7 >> > > >> >>>Trait that corresponds to this. Is this, in fact, the case? If >>so, we >> > > >> >> >> > > >> >>HL7 has no trait or PID element for this per se, although the RIM >>has >> > > >> >>different subtypes of person which are attributed differently. >>This is >> > > >>why >> > > >> >>I think the type is really a role or a profile type, rather than an >>ID >> > > >>type >> > > >> >>(even >> > > >> >>though some systems have for whatever reasons chosen to concatenate >> > > them >> > > >> >>into IDs. In practice I like to define distinct domains for >>patients, >> > > >> >>practitioners, etc, >> > > >> >>and then let the correlation Mgr track the correspondence - rather >>than >> > > >> >have >> > > >> >>multiple >> > > >> >>"persons" distinquished by type within an ID. Thats not a >>conceptually >> > > >> >>valid construct, >> > > >> >>unless we are defining a "profile identification service (PIDS)". >> > > >> >> >> > > >> >>There must be an intention to have exactly one distinct ID value >>per >> > > >> >>real-world person. >> > > >> >>There could be multiple profiles as long as they are consistent >> > > >> >> >> > > >> >>>should add a Trait which describes this type, but we must define >>the >> > > >> >>>"domain" of validity of the type. I see no reason to break the >>IDL. >> > > >> >> >> > > >> >>Right, it is a discrete, finite (but has to extensible) domain of >>valid >> > > >> >>values. >> > > >> >> >> > > >> >>> >> > > >> >>>The issue here also is that a "person" can have multiple types. >>Should >> > > >> >>I would stress multiple concurrent roles. To say a person is of >>some >> > > >> >"type" >> > > >> >>then that >> > > >> >>precludes the ability to support multiple concurrently applicable >> > > types. >> > > >> >>Just as a person >> > > >> >>could be BOTH a patient and a practitioner, this is not specifying >>what >> > > >> >type >> > > >> >>of person they >> > > >> >>this is specifying their ROLEs - or the subtypes (plural) of person >> > > that >> > > >> >>they instantiate. >> > > >> >> >> > > >> >>1) Therefore one way to approach this is to define a trait called >> > > >>"roles". >> > > >> >>it designates the roles this person plays. I think it is a mor >>precise >> > > >>word >> > > >> >>than "type" for this discussion. "Type" is a hopelessly overloaded >> > > term. >> > > >> >> >> > > >> >>2) Another is to assign, for each trait, the roles (plural) for >>which >> > > it >> > > >> >>applies as an attribute. For example, >> > > >> >>the family name and given name components are attributes of the >>(base >> > > >> >class) >> > > >> >>Person role, >> > > >> >>and a "policy IDs" trait might map to a "beneficiary" role, and a >> > > medical >> > > >> >>specialties trait might map to >> > > >> >>a practitioners role. >> > > >> >> >> > > >> >> >> > > >> >>I see four possible models here: >> > > >> >> >> > > >> >>1- a trait that conveys the set of roles this person is known to >>occupy >> > > >> >>(doesnt affect IDL) >> > > >> >> >> > > >> >>2- multiple profiles (of different profile roles) per person in the >> > > same >> > > >> >>domain, wherein each person still has exactly one id in a given >>domain; >> > > >> >>(breaks the candidate typedef and requires a new argument in >> > > get_profile) >> > > >> >> >> > > >> >>3 - one composite profile per person within a domain, with traits >>that >> > > >>are >> > > >> >>each associated with various roles, e.g. name (which applies to >>person >> > > >> >role) >> > > >> >>= Joe, medical specialty (which applies to person and practitioner >> > > roles) >> > > >>= >> > > >> >>OBGyn. The RIM reflects this kind of of subtype factoring, and the >> > > >>Message >> > > >> >>Development Framework (MDF) as used for Version 3 knows how to >>roll-up >> > > >> >>subtype attributes into segments or XML attributes, loosely >>speaking. >> > > I >> > > >> >>think the PMF understnads property inheritance as well. (need >>extend >> > > IDL >> > > >>to >> > > >> >>record the roles supported for each trait name). >> > > >> >> >> > > >> >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, >>wherein >> > > >>each >> > > >> >>domain supports exactly one role (Extend IdentifictionComponent so >>it >> > > can >> > > >> >>tell you what role the domain records) - and let the correlationMgr >>map >> > > >> >>them, or else let the client have the responsiblity to not log a >> > > >> >>practitioner profile into a purely-patient domain. The PIDS you >> > > connect >> > > >>to >> > > >> >>must be a CorrelationMgr to have knowledge of the different roles >>each >> > > of >> > > >> >>its persons occupies, but it would not know about "multiple >>profiles >> > > per >> > > >> >>person" as it is now defined. Note, however, that to say that it >> > > >>receives >> > > >> >>profiles of various roles is NOT the same as saying it has exactly >>one >> > > >> >>source domain per role. This is messy because it forces >>multi-domin >> > > >> >>semantics into the discussion of roles. >> > > >> >> >> > > >> >>Observations (not as in COAS): >> > > >> >>- the semantics of 1 and 2 are supported by 3, and 4; >> > > >> >>- the multiple profiles 2 can be derived from 3 but not 4 >> > > >> >>- 3 and 4 are not mutually exclusive. >> > > >> >>- all of these break the adopted IDL; 2 does not. >> > > >> >> >> > > >> >>Note to any implementors trying to decide which of these breaks >>your >> > > >> >>product: >> > > >> >>- Regardless of the approach taken, it is always valid for an MPI >> > > >> >>implementation to allocate IDs out of the same "integer-generating >> > > >> >sequence" >> > > >> >>for use in different domains. >> > > >> >> >> > > >> >> >> > > >> >>How do I decide? >> > > >> >>=================== >> > > >> >>I like 3 best because it has the richest semantics, is isomorphic >>with >> > > >> >HL7 - >> > > >> >>even gives HL7 a good reason to use the "identifier type" in their >> > > >> >>ExternalIDs struct, but functioning as a "profile type". 3 could >>also >> > > >> >>actually be turn-the-crank-derived from the RIM - all person >>attributes >> > > >>and >> > > >> >>person-subtype attributes would be defined as traits. We could >>even >> > > >> >define >> > > >> >>a compliance point by referencing a RIM version - and backwards >> > > >> >>compatibility just happens. Gorgeous V3 interoperablity without >> > > >> >>information loss in either direction. >> > > >> >> >> > > >> >>1 has an infinite benefit-to-modifications ratio, but 3 has a >>higher >> > > >> >>absolute benefit for an extension-only IDL modification >> > > >> >> >> > > >> >>>Jon Farmer writes: >> > > >> >>> > HL7's person IDs consist of >> > > >> >>> > >> > > >> >>> > Assigning authority + the "type" of identifier >>+ >> > > the >> > > >>id >> > > >> >>> > itself>. >> > > >> >>> > >> > > >> >>> > PIDS QualifiedPersonIDs has >> > > >> >>> > >> > > >> >>> > DomainName + PersonId >> > > >> >>> > >> > > >> >>> > Santosh points out the disparity between the HL7 three-part >> > > qualified >> > > >> >>IDs (a >> > > >> >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I >>totally >> > > >>agree >> > > >> >>we >> > > >> >>> > need to rectify the difference, however, I would not add "type" >>to >> > > >>the >> > > >> >>PIDS >> > > >> >>> > QualifiedPersonId, because (by definition of an ID domain) the >>ID >> > > >> >domain >> > > >> >>> > itself is adequate to disambiguate the id value. >> > > >> >>> > >> > > >> >>> > I think there is a better way to resolve it. Here is my >>analysis. >> > > >> >>> > >> > > >> >>> > Functionally, a person id is in fact nothing more than a coded >> > > >>concept >> > > >> >>(that >> > > >> >>> > just needs a unique coding schema and code part) for which the >> > > >>concept >> > > >> >>is a >> > > >> >>> > real world person. >> > > >> >>> > >> > > >> >>> > I believe that the HL7 use fo the identifier type is a >>pragmatic >> > > >> >>necessity >> > > >> >>> > for disambiguating the different roles that a newly registered >> > > person >> > > >> >>would >> > > >> >>> > play, or the "type" of profile being registeed for the >>real-world >> > > >> >>person. >> > > >> >>> > Any vendor that uses the same internal identifer domain for all >> > > >>persons >> > > >> >>in a >> > > >> >>> > system (like docs and patients) naturally needed a way to note >>the >> > > >> >>"type" of >> > > >> >>> > person, or the type of the profile in case there could be a >> > > distinct >> > > >> >>patient >> > > >> >>> > profile and doc profile for a given ID. It is functionlly an >> > > >>ATTRIBUTE >> > > >> >>that >> > > >> >>> > is commonly used as part of a primary key for profiles. >> > > >> >>> > >> > > >> >>> > Therefore I would recommend that, rather than replicate the >> > > >>less-formal >> > > >> >>HL7 >> > > >> >>> > artifact into our IDENTIFIER, lets incorporate it as an >>attribute >> > > of >> > > >>a >> > > >> >>> > PROFILE. There are two ways to do this - one that breaks the >>IDL >> > > and >> > > >> >>one >> > > >> >>> > that doesn't. >> > > >> >>> > >> > > >> >>> > To break the IDL we could change the definition of profile from >> > > >> >>> > >> > > >> >>> > typedef TraitSeq Profile; >> > > >> >>> > to >> > > >> >>> > struct Profile { >> > > >> >>> > ProfileType enum (patient, person, practitioner, >>whatever); >> > > >> >>> > ProfileTraits TraitSeq >> > > >> >>> > }; >> > > >> >>> > >> > > >> >>> > To keep the IDL intact we could predefine a trait called >> > > profileType. >> > > >> >>> > >> > > >> >>> > Finally, to provide for interoperationwithout requiring either >> > > party >> > > >>to >> > > >> >>> > break backward compatibility, we could stipulate as guidance >>(in >> > > both >> > > >> >>> > forums) an isomorphic transformatiion between the two, that is >>how >> > > to >> > > >> >>> > convert person IDs in either direction without info loss or >>without >> > > >>too >> > > >> >>much >> > > >> >>> > semantic abuse. >> > > >> >>> > >> > > >> >>> > Another IDL-breaking alternative is to make PIDS >>QualifiedPersonIDs >> > > >>an >> > > >> >>Any, >> > > >> >>> > that can be structured either way. Hwoever, this would >>introduce >> > > >> >>healthcare >> > > >> >>> > artifiacts in a way that would be totally confusing o PIDS >>users in >> > > >> >>other >> > > >> >>> > domains. >> > > >> >>> > >> > > >> >>> > Jon >> > > >> >>> > >> > > >> >>> X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 06 Nov 1999 15:48:04 -0700 To: sgandhi@mmm.com, "Jon Farmer" From: David Forslund Subject: Re: Fw: Issue 2872 need to define type of identifier Cc: "PIDS RTF" , Smith Becky , Leslie John In-Reply-To: <8625681D.00692516.00@em-stpmta-01.mmm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 8pD!!^d;e9'*;!!3Yf!! Here is how I've argued about adding a type to the TypedExternalId. I think there is merit to the idea, but the debate should still be whether it is wise (or appropriate) for this extension to be added through an RTF. Uniqueness of the QualifiedPersonId is required by the specification already, so uniqueness is not the issue, in my mind. The issue is how or should we add a further delimiting of the namespace to preserve this uniqueness, and I'm using as my model the work done for TQS and COAS. I certainly would appreciate feedback on this various possibilities. A proposed extension to ExternalID (2872) A QualifiedPersonId is a QualifiedName as defined by the NamingAuthority module. It is to be a globally unize name for an entity consisting of the AuthorityId and a LocalName (which is unique in the AuthorityId's namespace). PIDS/ExternalIds is a sequence of QualifiedPersonId's. The TerminologyService module of TQS (a.k.a., LQS) also uses QualifiedName with the ConceptCode corresponding to the LocalName of the QualifiedName.(Figure 5, of corbamed/99-03-22). The ExternalIDs can have different coding schemes to define special types of ExternalIDs. TQS could be used to get further definitions of these coding schemes and their applicable domain. Thus an ExternalID type for a Driver's License in a particular state would represent just one such coding scheme, which is assured to be unique within the issuing agency. Thus one could use QualifiedPersonId to include this coding scheme and the value (since it is simply a string) to provide various different ids with their own namespace. This would provide the type functionality without changing anything in the specification other than requiring parsing the localname to discover the true local Id part of the QualifiedPersonName. Example: DNS:va.gov/License/CA/123456AA In this case the Coded Concept is the License/CA with the value 123456AA, but all of this is part of the LocalName in QualifiedPersonId. Thus we have the equivalence of the type desired without having to introduce a totally new datatype within PIDS. This meaning goes slightly beyond the use of ConceptCode in TQS because it includes the "value" in the ConceptCode. To avoid this confusion of terminology, one might want to use the equivalent of QualifiedCodeInfo from the TQS specification: typedef string IntlString; struct QualifiedCodeInfo { QualifiedCode a_qualified_code; IntlString preferred_text; }; where QualifiedCode has the same content as QualifiedPersonId. In other words: typedef NamingAuthority::LocalName ConceptCode; typedef NamingAuthority::AuthorityId CodingSchemeId; struct QualifiedCode { CodingSchemeId coding_scheme_id; ConceptCode a_code; }; struct QualifiedPersonInfo { QualifiedCode a_qualified_code; PersonId id; } This would need to be in a new Trait in module PersonIdTraits: typedef sequence QualfiedPersonInfoSeq; const PersonIdService::TraitName EXTERNAL_CODED_IDS = "PIDS/ExternalCodedIds"; typedef PersonIdService::QualifiedPersonInfoSeq ExternalCodedIdsType; This avoids ambiguity in the meaning of an Id of a person from an external coding system. It should not break any other parts of the PIDS service. It probably should be an optionally supported type. With this approach the QualifiedCodeStr for the example above would be DNS:va.gov/License/CA and the PersonId would be 123456AA. I believe this could easily handle the request to support the HL7 namespace for Ids. The debate is whether this extension is a true ambiguity or error in the current PIDS specification or should become part of an extended service such as a Person Locator Service that might have much enhanced functionality over the current PIDS. Even if such a new service dealt with this issue, this change might be desirable in order to provide a linkage to this new service, but this is beyond the scope of this RTF. This entire issue could also be handled by the proposed response to Issue #2736 (perhaps in concert with #2670), where this type (or even the proposed struct) would be handled with a dynamic trait which could be "discovered" through a DynAny and whose type and support could be handled by the added type or property call to a user defined traittype. Dave At 12:05 PM 11/2/99 -0700, sgandhi@mmm.com wrote: >Jon - I am sorry for the confusion. What I meant was: in a set of External >IDs for a person, same domain can not assign two identifiers of the same >type. So you could have a license number (Identifier type) from State1 >(domain) and another license number (Identifier 's type) from State 2 >(domain), but you can not have two license numbers from the same State >(domain). >So a set of External Ids may look like: > >{DomainName UT >PersonId 897654 >IdType License Number}, > >{DomainName DOD Walter Reed > PersonId 12456 >IdType MRN}, > >{DomainName Indian Health Services > PersonId 34567 > IdType Tribal Enrollment Number} > > > > >"Jon Farmer" on 10/25/99 02:24:56 PM > >Please respond to "Jon Farmer" > > >To: "PIDS RTF" >cc: (bcc: Santosh Gandhi/HI-HealthInfo/3M/US) >Subject: Fw: Issue 2872 need to define type of identifier > > > > >Santosh has specified that identifier types among a set of ExternalIDs must >be unique. If I understand this correctly, this means that no two of the >Qualified Person IDs in a given ExternalIDs trait can have the same >identifier type. I suspect that we cannot accept this assumption, since >there are an arbitrarily large number of id-assigners for a given >real-world >person, and there is no way they coordinate wtih each other tomake sure >that >only one of them is "using" the SSN or the MRN. I think it's precisely >this >autonomy that makes correlation necessary in the first place. Santosh can >you defend the uniqueness assumption? or maybe I misunderstood, in which >case I probably need an example. >Jon >-----Original Message----- >From: Jon Farmer >To: Jon Farmer ; David W. Forslund >Cc: pids-rtf2@omg.org >Date: Thursday, October 21, 1999 7:11 PM >Subject: Re: Issue 2872 need to define type of identifier > > > >Santosh and others, > > > >I think Dave's proposal not only meets your needs, but also the "role" > >oriented kind of thing I was trying to force-fit into it. Here is how I > >would summarize the various requirements (the ones you raised and I >raised) > >and how Dave's solution could address them. > > > >1) in cases where an "identifier type" is NEEDED to uniquely identify the >id > >domain, it could be concatenated by the client to construct the existing >ID > >domain - as the client sees fit. This would keep us from contaminating >the > >definition of an ID domain. > > > >2) For the case in which the type is not needed in order to make the ID > >domain unambiguous, but the application environment still needs a way to > >"qualify" the ID, as Santosh descibed - we could define a Trait to carry >it, > >or an enhanced trait like External IDs that carries the "enhanced External > >IDs." Maybe call it TypedExternalIDs. We need some advice or feedback > >here as to what that would be called. Would this approach suffice for the > >GCPR? I think this is most pivotal remaining issue in the whole RTF. > > > >3) to convey the notion of roles (which is implied in some of the HL7 >values > >for type) without mixing it up with the type, a distinct trait perhaps > >called roles or even relationships could be defined by local agreement. > > > >It appears these three approaches meet all our requirements without >breaking > >the existing IDL. We might consider now whether we need to define the >new > >traits ( 2 and 3) as "new standard traits", or just leave it up to local > >agreement. > > > >Dave F points out that in the Party Management Facility (PMF), roles and > >relationships are explicit in IDL as first class objects (interfaces). >Hey > >Dave - can the trait's ANY carry an IOR? > > > > > > > >-----Original Message----- > >From: Jon Farmer > >To: David W. Forslund > >Cc: pids-rtf2@omg.org > >Date: Thursday, October 14, 1999 8:50 PM > >Subject: Re: Issue 2872 need to define type of identifier > > > > > >> > >>-----Original Message----- > >>From: David W. Forslund > >>To: Jon Farmer > >>Cc: pids-rtf2@omg.org > >>Date: Thursday, October 14, 1999 6:28 PM > >>Subject: Re: Issue 2872 need to define type of identifier > >> > >> > >>>I believe the best solution here is to have an a Trait which identifies > >>>the "type" of a person. It would appear that there is no simple HL7 > >>>Trait that corresponds to this. Is this, in fact, the case? If so, we > >> > >>HL7 has no trait or PID element for this per se, although the RIM has > >>different subtypes of person which are attributed differently. This is >why > >>I think the type is really a role or a profile type, rather than an ID >type > >>(even > >>though some systems have for whatever reasons chosen to concatenate them > >>into IDs. In practice I like to define distinct domains for patients, > >>practitioners, etc, > >>and then let the correlation Mgr track the correspondence - rather than > >have > >>multiple > >>"persons" distinquished by type within an ID. Thats not a conceptually > >>valid construct, > >>unless we are defining a "profile identification service (PIDS)". > >> > >>There must be an intention to have exactly one distinct ID value per > >>real-world person. > >>There could be multiple profiles as long as they are consistent > >> > >>>should add a Trait which describes this type, but we must define the > >>>"domain" of validity of the type. I see no reason to break the IDL. > >> > >>Right, it is a discrete, finite (but has to extensible) domain of valid > >>values. > >> > >>> > >>>The issue here also is that a "person" can have multiple types. Should > >>I would stress multiple concurrent roles. To say a person is of some > >"type" > >>then that > >>precludes the ability to support multiple concurrently applicable types. > >>Just as a person > >>could be BOTH a patient and a practitioner, this is not specifying what > >type > >>of person they > >>this is specifying their ROLEs - or the subtypes (plural) of person that > >>they instantiate. > >> > >>1) Therefore one way to approach this is to define a trait called >"roles". > >>it designates the roles this person plays. I think it is a mor precise >word > >>than "type" for this discussion. "Type" is a hopelessly overloaded term. > >> > >>2) Another is to assign, for each trait, the roles (plural) for which it > >>applies as an attribute. For example, > >>the family name and given name components are attributes of the (base > >class) > >>Person role, > >>and a "policy IDs" trait might map to a "beneficiary" role, and a medical > >>specialties trait might map to > >>a practitioners role. > >> > >> > >>I see four possible models here: > >> > >>1- a trait that conveys the set of roles this person is known to occupy > >>(doesnt affect IDL) > >> > >>2- multiple profiles (of different profile roles) per person in the same > >>domain, wherein each person still has exactly one id in a given domain; > >>(breaks the candidate typedef and requires a new argument in get_profile) > >> > >>3 - one composite profile per person within a domain, with traits that >are > >>each associated with various roles, e.g. name (which applies to person > >role) > >>= Joe, medical specialty (which applies to person and practitioner roles) >= > >>OBGyn. The RIM reflects this kind of of subtype factoring, and the >Message > >>Development Framework (MDF) as used for Version 3 knows how to roll-up > >>subtype attributes into segments or XML attributes, loosely speaking. I > >>think the PMF understnads property inheritance as well. (need extend IDL >to > >>record the roles supported for each trait name). > >> > >>4 - track role-distinct distinct profiles in SEPARATE DOMAINS, wherein >each > >>domain supports exactly one role (Extend IdentifictionComponent so it can > >>tell you what role the domain records) - and let the correlationMgr map > >>them, or else let the client have the responsiblity to not log a > >>practitioner profile into a purely-patient domain. The PIDS you connect >to > >>must be a CorrelationMgr to have knowledge of the different roles each of > >>its persons occupies, but it would not know about "multiple profiles per > >>person" as it is now defined. Note, however, that to say that it >receives > >>profiles of various roles is NOT the same as saying it has exactly one > >>source domain per role. This is messy because it forces multi-domin > >>semantics into the discussion of roles. > >> > >>Observations (not as in COAS): > >>- the semantics of 1 and 2 are supported by 3, and 4; > >>- the multiple profiles 2 can be derived from 3 but not 4 > >>- 3 and 4 are not mutually exclusive. > >>- all of these break the adopted IDL; 2 does not. > >> > >>Note to any implementors trying to decide which of these breaks your > >>product: > >>- Regardless of the approach taken, it is always valid for an MPI > >>implementation to allocate IDs out of the same "integer-generating > >sequence" > >>for use in different domains. > >> > >> > >>How do I decide? > >>=================== > >>I like 3 best because it has the richest semantics, is isomorphic with > >HL7 - > >>even gives HL7 a good reason to use the "identifier type" in their > >>ExternalIDs struct, but functioning as a "profile type". 3 could also > >>actually be turn-the-crank-derived from the RIM - all person attributes >and > >>person-subtype attributes would be defined as traits. We could even > >define > >>a compliance point by referencing a RIM version - and backwards > >>compatibility just happens. Gorgeous V3 interoperablity without > >>information loss in either direction. > >> > >>1 has an infinite benefit-to-modifications ratio, but 3 has a higher > >>absolute benefit for an extension-only IDL modification > >> > >>>Jon Farmer writes: > >>> > HL7's person IDs consist of > >>> > > >>> > Assigning authority + the "type" of identifier + the >id > >>> > itself>. > >>> > > >>> > PIDS QualifiedPersonIDs has > >>> > > >>> > DomainName + PersonId > >>> > > >>> > Santosh points out the disparity between the HL7 three-part qualified > >>IDs (a > >>> > CX datatype) and the two-part PIDS qualifiedPersonIds. I totally >agree > >>we > >>> > need to rectify the difference, however, I would not add "type" to >the > >>PIDS > >>> > QualifiedPersonId, because (by definition of an ID domain) the ID > >domain > >>> > itself is adequate to disambiguate the id value. > >>> > > >>> > I think there is a better way to resolve it. Here is my analysis. > >>> > > >>> > Functionally, a person id is in fact nothing more than a coded >concept > >>(that > >>> > just needs a unique coding schema and code part) for which the >concept > >>is a > >>> > real world person. > >>> > > >>> > I believe that the HL7 use fo the identifier type is a pragmatic > >>necessity > >>> > for disambiguating the different roles that a newly registered person > >>would > >>> > play, or the "type" of profile being registeed for the real-world > >>person. > >>> > Any vendor that uses the same internal identifer domain for all >persons > >>in a > >>> > system (like docs and patients) naturally needed a way to note the > >>"type" of > >>> > person, or the type of the profile in case there could be a distinct > >>patient > >>> > profile and doc profile for a given ID. It is functionlly an >ATTRIBUTE > >>that > >>> > is commonly used as part of a primary key for profiles. > >>> > > >>> > Therefore I would recommend that, rather than replicate the >less-formal > >>HL7 > >>> > artifact into our IDENTIFIER, lets incorporate it as an attribute of >a > >>> > PROFILE. There are two ways to do this - one that breaks the IDL and > >>one > >>> > that doesn't. > >>> > > >>> > To break the IDL we could change the definition of profile from > >>> > > >>> > typedef TraitSeq Profile; > >>> > to > >>> > struct Profile { > >>> > ProfileType enum (patient, person, practitioner, whatever); > >>> > ProfileTraits TraitSeq > >>> > }; > >>> > > >>> > To keep the IDL intact we could predefine a trait called profileType. > >>> > > >>> > Finally, to provide for interoperationwithout requiring either party >to > >>> > break backward compatibility, we could stipulate as guidance (in both > >>> > forums) an isomorphic transformatiion between the two, that is how to > >>> > convert person IDs in either direction without info loss or without >too > >>much > >>> > semantic abuse. > >>> > > >>> > Another IDL-breaking alternative is to make PIDS QualifiedPersonIDs >an > >>Any, > >>> > that can be structured either way. Hwoever, this would introduce > >>healthcare > >>> > artifiacts in a way that would be totally confusing o PIDS users in > >>other > >>> > domains. > >>> > > >>> > Jon > >>> X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 07 Nov 1999 22:57:13 -0700 To: sgandhi@mmm.com, "Jon Farmer" From: David Forslund Subject: Re: Fw: Issue 2872 need to define type of identifier Cc: "PIDS RTF" , Smith Becky , Leslie John In-Reply-To: <4.2.0.58.19991106154140.03a79f00@cic-mail.lanl.gov> References: <8625681D.00692516.00@em-stpmta-01.mmm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: -Z`d9:X-!!(l From: "Jon Farmer" To: "Smith Becky" , , "David Forslund" Cc: "Leslie John" , Subject: Re: Fw: Issue 2872 need to define type of identifier Date: Mon, 8 Nov 1999 20:37:23 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %EZ!!YSad9JQ+e9[D0e9 see inline -----Original Message----- From: David Forslund To: Smith Becky ; sgandhi@mmm.com ; Jon Farmer Cc: Leslie John Date: Monday, November 08, 1999 12:01 PM Subject: RE: Fw: Issue 2872 need to define type of identifier >At 08:10 AM 11/8/99 -0500, Smith Becky wrote: >>Yes, at this point GCPR doesn not need to track traits corresponding to >>multiple roles. All we need is to know more about the external id's. We are >>trying to use the MPI as our locator - the domain gives us some information Not to make the immediate problem bigger than it is, but the notion of location adds more attractivenes to the new trait argument: How about typedef ExternalIdsExtendedInfo that adds for each ExternalID (a) its type and (b) a sequence of IORs or Names for services containing content for that domain? Now that I have stated it, the idea repulses me froma security and robustness perspective (needs effective date ranges and potentially far more administrative info available. Forget it. >>but maybe not enough. Also, DoD has sponsor SSN and DEERS number. Both are >>external ids but I need to know which the id is so I know where it has >>meaning. I believe it would be easier, more standard and less ambiguous to >>have "type" in a defined field, rather than parse for it. > >Doing it via 1) would be the "standard" way because it involves no changes >in the interface. I don;t like the idea of embeddng the type into the id-value part of the identifer any more than I liked embedding it intothe domain part. It corupts both. In either case it would be imperative for the client and server side to know how to strip it out. Even worse, since a given value in a given version 1 domain could get two types assigned based on differences in USAGE, there could be two legitimate values for a given person. To me this feels like it breaks version one implementations at least as bad as a change in IDL would break it. >2) may be less ambiguous, but would require a modification of the >standard. It certainly can be >done in the GCPR without change the PIDS standard but would affect future >interoperability. What happened to the TypeExternalID proposal? The number 2 shown below shows QualifiedPersonInfo - I thought we needed to add ID info not person info. The type is not a person attribute, it is an attribute of the identifier. Nevertheles, I think that a solution that adds a predefined trait is better than one that breka an existing one or introduces parsing requirements to implementations PIDS is still young enough to extend the basic traits for the sake of GCPR and a clear HL7 mapping >3) can be done with on change in the IDL but needs an agreement as to the >use of more complex traits as >part of the standard. The ability to request the Property of a Trait would >be useful in this context so that the semantics >would be unambiguous. I think 3 is the ultimate elegant solution since we will eventually need dynamic metadata and fll XML interoperation anyway. The only problem with this is that until ANSI and HL7 decide how they will define data types in XML DTDs, we would be premature in whatever we recommend next week. How about go with something like (2) for this RTF and then let PIDS RFP 2 map it to DTDs? > >Dave > > >>-----Original Message----- >>From: David Forslund [mailto:dwf@lanl.gov] >>Sent: Monday, November 08, 1999 12:57 AM >>To: sgandhi@mmm.com; Jon Farmer >>Cc: PIDS RTF; Smith Becky; Leslie John >>Subject: Re: Fw: Issue 2872 need to define type of identifier >> >> >>Let me summarize the three approaches that I see: >> >>1) Use subfields in the localname of QualifiedPersonId to specify a type >>such as license number for the ExternalId. This >>represents no change in the spec, but some added words perhaps for guidance. >> >>2) Add a new type QualifiedPersonInfo which has a QualifiedCode and a >>PersonID. This enables a fairly comprehensive >>mechanism to define the concept underlying the new ExternalID type. >> >>3) Utilize a more dynamic data type approach which could be expressed >>through XML, so that the type information would be >>included. This could simply be dynamically discovering the >>QualifiedPersonInfo structure. >> >>There are pros and cons to each approach and I won't debate them here. >> >>Dave > > X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 08 Nov 1999 21:25:28 -0700 To: "Jon Farmer" , "Smith Becky" , From: David Forslund Subject: Re: Fw: Issue 2872 need to define type of identifier Cc: "Leslie John" , In-Reply-To: <008401bf2a53$e24220e0$891e85cd@JGFNT.toledolink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: #4H!!^3J!!#R/!!aL?!! At 08:37 PM 11/8/99 -0500, Jon Farmer wrote: >see inline >-----Original Message----- >From: David Forslund >To: Smith Becky ; sgandhi@mmm.com ; >Jon Farmer >Cc: Leslie John >Date: Monday, November 08, 1999 12:01 PM >Subject: RE: Fw: Issue 2872 need to define type of identifier > > > >At 08:10 AM 11/8/99 -0500, Smith Becky wrote: > >>Yes, at this point GCPR doesn not need to track traits corresponding to > >>multiple roles. All we need is to know more about the external id's. We >are > >>trying to use the MPI as our locator - the domain gives us some >information > >Not to make the immediate problem bigger than it is, but the notion of >location adds more attractivenes to the new trait argument: >How about typedef ExternalIdsExtendedInfo that adds for each ExternalID (a) >its type and (b) a sequence of IORs or Names for services containing content >for that domain? Now that I have stated it, the idea repulses me froma >security and robustness perspective (needs effective date ranges and >potentially far more administrative info available. Forget it. I agree. > >>but maybe not enough. Also, DoD has sponsor SSN and DEERS number. Both are > >>external ids but I need to know which the id is so I know where it has > >>meaning. I believe it would be easier, more standard and less ambiguous to > >>have "type" in a defined field, rather than parse for it. > > > >Doing it via 1) would be the "standard" way because it involves no changes > >in the interface. >I don;t like the idea of embeddng the type into the id-value part of the >identifer any more than I liked embedding it intothe domain part. It >corupts both. In either case it would be imperative for the client and >server side to know how to strip it out. Even worse, since a given value in >a given version 1 domain could get two types assigned based on differences >in USAGE, there could be two legitimate values for a given person. To me >this feels like it breaks version one implementations at least as bad as a >change in IDL would break it. Use of this approach should require a normative statement in the Spec indicating how it should be used. > >2) may be less ambiguous, but would require a modification of the > >standard. It certainly can be > >done in the GCPR without change the PIDS standard but would affect > future > >interoperability. > >What happened to the TypeExternalID proposal? The number 2 shown > below >shows QualifiedPersonInfo - I thought we needed to add ID info not > person >info. The type is not a person attribute, it is an attribute of the >identifier. This is perhaps a bad name, QualifiedPersonIdInfo probably would be a better name. I followed the patterns from TQS and COAS in which we can have a full fledged conceptcode to define the ID type. >Nevertheles, I think that a solution that adds a predefined trait is better >than one that breka an existing one or introduces parsing requirements to >implementations PIDS is still young enough to extend the basic traits for >the sake of GCPR and a clear HL7 mapping Can we argue for its adoption in this RTF? Can we argue the ExternalID spec is incomplete and needs more information. Sounds like the need for an HL7 mapping might be the best argument. > >3) can be done with on change in the IDL but needs an agreement as to the > >use of more complex traits as > >part of the standard. The ability to request the Property of a Trait would > >be useful in this context so that the semantics > >would be unambiguous. > >I think 3 is the ultimate elegant solution since we will eventually need >dynamic metadata and fll XML interoperation anyway. The only problem with >this is that until ANSI and HL7 decide how they will define data types in >XML DTDs, we would be premature in whatever we recommend next week. > >How about go with something like (2) for this RTF and then let PIDS RFP 2 >map it to DTDs? I think it is probably premature to define XML DTDs, but the spec fully allows their use now. What about the Property of a Trait? If we get that in the spec, then it is at least discoverable by the client. I appreciate your insight on this. Dave > > > >Dave > > > > > >>-----Original Message----- > >>From: David Forslund [mailto:dwf@lanl.gov] > >>Sent: Monday, November 08, 1999 12:57 AM > >>To: sgandhi@mmm.com; Jon Farmer > >>Cc: PIDS RTF; Smith Becky; Leslie John > >>Subject: Re: Fw: Issue 2872 need to define type of identifier > >> > >> > >>Let me summarize the three approaches that I see: > >> > >>1) Use subfields in the localname of QualifiedPersonId to specify > a type > >>such as license number for the ExternalId. This > >>represents no change in the spec, but some added words perhaps for >guidance. > >> > >>2) Add a new type QualifiedPersonInfo which has a QualifiedCode > and a > >>PersonID. This enables a fairly comprehensive > >>mechanism to define the concept underlying the new ExternalID > type. > >> > >>3) Utilize a more dynamic data type approach which could be > expressed > >>through XML, so that the type information would be > >>included. This could simply be dynamically discovering the > >>QualifiedPersonInfo structure. > >> > >>There are pros and cons to each approach and I won't debate them > here. > >> > >>Dave > > > > From: sgandhi@mmm.com X-Lotus-FromDomain: 3M-CORPORATE To: issues@emerald.omg.org, pids-rtf2@emerald.omg.org Message-ID: <86256828.00043371.00@em-stpmta-01.mmm.com> Date: Fri, 12 Nov 1999 17:42:09 -0700 Subject: Re: issue 2872 -- PIDS RTF 2 ISSUE Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: k;md9(i,e9=Ncd9cB2!! OMG Issue No: 2872 Title: need to define "type" of identifer Source: 3M Santosh Gandhi sgandhi@mmm.com Summary: There is a trait in the PersonIdTraits module - PIDS/ExternalIds and its type is QualifiedPersonIdSeq. We need another data type for this trait - which will correspond to the HL7 datatype of CX for the patient's Identifiers, e.g. it should have the assigningAuthority, 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. Resolution: Add a new trait PIDS/ExternalCodedIds to the PersonIdTraits module which will have the data type of QualifiedPersonIdInfoSeq. typedef sequence QualfiedPersonIdInfoSeq; const PersonIdService::TraitName EXTERNAL_CODED_IDS = "PIDS/ExternalCodedIds"; typedef PersonIdService::QualifiedPersonIdInfoSeq ExternalCodedIdsType; typedef NamingAuthority::AuthorityId CodingSchemeId; struct QualifiedCode { CodingSchemeId coding_scheme_id; ConceptCode a_code; }; struct QualifiedPersonIdInfo { QualifiedCode a_qualified_code; QualifiedPersonId id; } CodingSchemeId used by the Qualifiedcode can be the HL7 table 0203 for Identifier type and the value set can be the contents of the table and the QualifiedPersonId will be the PersonId in the specified domain. TQS could be used by PIDS to get the Identifier Type . X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 18 Nov 1999 05:28:46 -0700 To: issues@emerald.omg.org, pids-rtf2@emerald.omg.org From: David Forslund Subject: Re: Issue 2872 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: K7J!!MO$e9Ad*!!<"%e9 Proposed resolution: Rules for creating unique QualifiedNames are described in page 2-47 of the current PIDS specification. Within the IDL RegistrationAuthority, LocalName can have any characters. Also, the IdentificationComponent has a string, QualifiedNameStr component_name, to name the particular PIDS service. In order to create and manage unique IDs, it is acceptable to include the component_name in the LocalName of the QualifiedPersonId to further delimit the name space. Thus QualifiedPersonIds could have information in them which allows one to determine the specifics of the server (accessible through the NamingService, e.g.) to locate the id of the person. This could also include other naming schemes for specific ids in a different name space for local management of certain Id types.