The HL7 version 3 data type task group has had its sixteenth conference call on Monday, February 15, 1999, 11:00 to 12:30 EST.
Attendees were:
Agenda items were:
We enjoyed three "guests" from the PAFM TC among us: Norman Daoust, John Molina, and Richard Ohlmann. It was very helpful to have them with us.
External identifiers for real world people and things occur frequently. Examples for people identifiers are Social Security Number, Driver License Number, Passport Number, Individual Taxpayer Identification Number. Identifiers for organizations are, e.g., the federal identification number or the Employer Identification Number. The current approach in the RIM is to use the Stakeholder_identifier class for those numbers.
Here are some of those identifiers used in the U.S.
Other countries may or may not have similar identifiers. The interesting point is that such identifiers are often used for other than the original purposes. For example, very few U.S. people care about whether you have a license to drive, but they do want your driver license number anyway in order to get hold of your identity (e.g., in check issuing.) The U.S. SSN may officially not be used by everyone, but that does not keep everyone from using it as a pretty reliable person identifier. Banks and employers must collect the SSN of their customers and employees (resp.) for tax purposes.
[You notice it is Tax season, and I get myself acquainted with the U.S. Tax system.]
However, there are other such identification numbers, not issued for persons. Those numbers have basically the same semantics and the same requirements, except that those numbers might be assigned for other real world instances other than people or organizations. Examples are things, such as devices and durable material (inventory numbers), charge and lot numbers (?), etc.
The public health / animal proposal, for example, has a concrete need for the following identification numbers:
Such real world instance identifiers are assigned not only by big organizations but also by smaller organizations. For example, virtually every organization puts tags with numbers on their inventory.
Medical Record Numbers (MRN) as used in the world of Paper Medical Records are another example for such real world instance identifiers. Note that in the computer world, we would not need MRNs, since we could use Technical Instance Identifiers (TII) to refer to computerized medical records. However, Wes Rishel and I think that as a rule of thumb, TIIs should not be communicated through human middlemen in order to keep reliability in their correctness high. Thus, as long as MRNs are typed in by clerks and other people, one should separate them from TIIs.
The basic structure of such a real world instance identifier is:
| identifier_text | CharacterString |
| validity_period | Interval of PointInTime (i.e., begin and end dttm) |
| issuing_authority | ??? |
The main methodological question is how we represent the identifier assigning authority. This would usually be an organization. An organization is generally a stakeholder, and such would an issuing authority be represented by an association to stakeholder (or, more specific, to organization). It is basically what the Stakeholder_identifier class does.
However, this is also a problem. We are able to carry quite a lot of information about the identifier assigning authority, which is good. But the structure looks rather complex, which is bad. Particularly, while we all know that SSN, DLN, etc are issued by organizations, we do not care so much about that organization. The only thing we want to know is that a given number is an SSN.
However, things become tricky if we try to shortcut. The problem is that SSN and DLN are valid in realms defined by the issuing authorities. For example, for a DLN we need to know the state. For an SSN in an international context, we need to know the country.
To me, it seems as if we want to keep the link to stakeholder as an assigning authority. Thus an Indiana drivers license would be represented as having the "Indiana Bureau of Motor Vehicles (BMV)" as an issuing authority. Which brings us into trouble, because someone in California might not know that there is a BMV in Indiana. The BMV, of course, is an affiliate of the state of Indiana.
Do we have to carry about the stakeholder-affiliate loop just to make clear that a given DLN is an Indiana driver license? What about international contexts: do we have to go once more through the stakeholder-affiliate loop so that the receiver can find out that Indiana is actually a part of the U.S.?
While this may be the correct solution, it seems to be rather impractical.
The major issue by which PAFM will be affected is that we want to have a general such identifier class or type that can be used not only to identify stakeholders but also things and animals.
The goal of this redesign is to come up with only one data type for such Rela World Instance Identifiers. If we have a data type that takes on the tasks of the Stakeholder_identifier class, we can reuse it for entities other than people and organizations. But we can also reuse this data type in order to put the identifiers for stakeholders in their proper place in the model, instead of pushing them all up into the highest level of the hierarchy, i.e. the Stakeholder class.
The following options exist in principle
Association with stakeholder (or organization) as the assiging authority. A clean, but somewhat verbous heavy weight way, as described.
| Real World Instance Identifier (RWII) | |
|---|---|
| value | CharacterString |
| authority | reference to Organization |
In this alternative we pointing out to an Organization class instance from inside the data type? This is a weird construct that we have never seen before in the world of the RIM vs. Data Types dichotomy.
The remaining three alternatives are essentially the same as this one, except they specify different ways to represent this "reference to Organization".
The Organization as an assigning authority would itself have one or more RWIIs. Thus, one represent the assigning authority recursively as a RWII.
| Real World Instance Identifier (RWII) | |
|---|---|
| value | CharacterString |
| authority | RWII |
This is a specific way to make the reference to an assigning authority Organization, i.e. by looking up the organization through its RWII.
An OID for assigning authority, which structurally renders the RWII similar to the TII but with a very different semantics.
| Real World Instance Identifier (RWII) | |
|---|---|
| value | CharacterString |
| authority | ISO Object Identifier |
This alternative, while structurally similar to the TII is in fact very different. The TII is supposed to be globally and dependably unique. This dependable uniqueness, can not be required from real world identifiers, that are ofthen reported orally or on paper. Morover, such numbers are often reused either accidentially (roll-over of counters) or voluntarily (old number considered outdated).
The traditional way to represent assiging authority would be through a single "code" from some "master table"
| Real World Instance Identifier (RWII) | |
|---|---|
| value | CharacterString |
| authority | CharacterString |
I don't like 3 and 4. Both are seemingly simple but they do lead to practicability problems. They don't scale. The OID is pseudo-unique. What is the OID of the state of Indiana? 3 and 4 end up being the same, you have to interpret the authority part from some unknown table. That would be possible if our identifiers would only be such official things as SSN, ITIN, EID, FID, DLN, etc. But as Norman points out, the medical record numbers are assigned locally. Also Inventory numbers for devices are assigned locally. So, I really hate options 3 and 4.
Mark Shafarman says that such a Data Type seems to violate the MDF in its rule that forreign keys should not be used. Indeed, alternatives 2 through 4 do use various schemes of forreign keys. Alternative 1 is principally open to whether or not forreign keys are used, but if Datatypes are considered different from RIM classes the question is hos such an association from a data type to a RIM class could be made.
Mark Tucker sais the wise words:
This data type wants to be a forreign key.And indeed this data type embodies the fact that we use "keys" in order to refer to things accross (foreign) models.
Mark Tucker further offers the following "trick" to make alternative 4 useable and - to a certain extent - interoperable: People could use use local codes for assiging authorities within their usual communication horizon, assuming that master tables would be synchronized. For outside communication, a "row" of such a master table could just be included in the message. This master table row would be used to map "strings" to "things".
The advantage is that it allows for very short forms of identifiers. Conversely, representing assiging authority as an Organization instance (alternative 1) would lead to ugly messages.
However, two problems arise:
It is not guarranteed that the strings for assigning authorities wouls be unioque within a message.
How would we represent this "master file" construct?
Norman Daoust says that the Stakeholder hierarchy basically is such a master file structure. Thus the question is why we would represent associations to "master" stuff differently for this data type than for RIM classes.
This discussion seemed to be sticky, which is why we got rid of it by agreeing to put this "data type" as a class directly into the RIM. This allows the "data type" to associate with other classes, such as organization. From this "data type" we can defined "CMET" and we can implement those on ITSs however we like. For now, we need not be bogged down by this discussion how we would represent this structure in a message.
We decided upon a number of RIM changes to vote on in the upcoming HL7 meeting. The following figure shows the structure around Stakeholder_identifier as of RIM 0.88t.
|
| Figure 1: Stakeholder_identifier as of RIM 0.88t. |
|---|
The following diagram shows the effect of the proposed changes.
 |
| Figure 2: The Stakeholder_Identifier has become the "Real World Instance Identifier" and is thus useful for other things, such as the inventory number of medical devices. |
|---|
Here are the changes in detail
Rationale: this class will undergo a broadening of scope. PAFM therefore no longer has to take the burden of maintaining this class for everyone else. That's what Control/Query is for.
Rationale: to signify the broadening of this classe's scope.
Definition: An assigin authority may want to maintain different namespaces in which the identifiers are unique. Those namespaces are created in the full descretion of the assiging authority and might have no globally understood meaning. By contrast, the identifier type code is a globally understood classification of the identifier. A "unique" real world instance identifier is the triple of value, namespace, and assiging authority.
Rationale: the two attributes effective_dt and termination_dt were used to signify the validity period of the identifier. A period of time can more properly (and more compact) be represented by the new data type Interval of Point in Time. This allows for infinite as well as unknown begin and termination dates.
Rationale: it is unclear why date of issuing differs from effective date. There seems to be no usecase to me (PAFM folks: please confirm or defend!)
Rationale: the use of this attribute is in part taken over by "namespace". Where it is not handled through namespace different assiging authorities should be used. This prevents the same information to be representable in different ways.
Rationale: nobody could define the use case of this class. It seems to be a modeling stereotype ("role class") that is not uesful in practice. The intention is to simplify the model where possible.
Rationale: in an international use context of HL7 it is necessary to keep track of the "citizenship" of organizations as well as of individual persons.
Rationale: A shorter name is easier to read, write, speak and memorize.
Rationale: The difference between citizenship and nationality is unclear, did not exist in HL7 v2.x, and thus, can be deleted.
The following are my suggestions to Richard for simplification of the stakeholder affiliation issues. These things are not essential to the Control Query related requirements. Nevertheless, since the stakeholder affiliation loop would be used by all of Control Queries "customers" we have an interest in this to be as cumberless as possible.
Rationale: This additional relationship class on the "secondary" leg of stakeholder affiliate was primarily a modeling stereotype of little known practical use. The familiary relationship can as well be carried by the stakeholder affiliate class where applicable. This leads to a model that is simpler to use and simpler to understand while maintaining the same level of expressiveness and explicity.
Rationale: this subdividing of organizations is a kind of "affiliation" relationship, which would also be expresed by the "Stakeholder_affiliation" class. There should be only one way of expressing affiliations (including subdivision). Stakeholder_affiliation.family_relationship_cd should have a value reserved for subdivision of organizations. Note that affiliation_type code is to express the "purpose" of a particular affiliation (e.g. emergency contact), while family_relationship is the durable relationship between stakeholders throughout all purposeful affiliations.
Richard, Norm, Freida, could we meet at some night in Toronto. I would like to evoke and discuss major simplification opportunities of the upper far-left side of the RIM. IMHO there are very many "small" classes that create a maze of associations. A simplified model would greatly facilitate understanding, correct use as well as message design!
New Association: classes that would have a real world instance identifier, such as, "Durable_medical_equipment" should be associated to the RealWorldInstanceIdentifier class to exemplify its use.
This is basically a stepwise RIM change as would be required for Harmonization. We will discuss this with PAFM and other affected technical committees at the next HL7 meeting (Toronto).
This conference call was very effective. We could indeed bring this issue to a closure. I'd like to thank everyone - especially our advisers from PAFM - for their help!
Next conference call is next Monday, Feb 22, 1999, 11:00 AM EST.
Agenda items are:
regards
-Gunther Schadow