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 ex