Datatypes R2 Issue 57
Contents
Data Types Issue 57: II.useCode
Introduction
This proposal is for a useCode on II. This idea was endorsed in principle by MnM (see motion below).
MnM Motion
To ease the adoption of HL7 v3, MnM recommends INM to add “useCode” to II. This would identify the intended scope/purpose/use of the identifier. See also the discussion around Types of Identifiers. Example concepts to be included:
- Issued by scoper/author
- Verified by scoper/author
- Used by scoper/author
- Non-player specific
- Real-world id
- Record id
- Version-specific (snapshot)
- View id
- Reference
- Definitional
(The difference between reference and definition is that when the id is definitional the sender is conveying to the receipient all the necessary information for this context of use. This is not the same as the source of truth)
MnM would like to participate in identifying requirements, appropriate contents, definitions and usage guidelines
Default values will be set to make the attribute backwards compatible
see also Types of Identifiers
Proposal
There was long and passionate discussion on this issue. below, in original proposal, is the initial domain defined for discussion. We ended up with a proposal to have two separate attributes, as this is a lot cleaner.
Attribute Reliability
reliability : CS
This attribute specifies the reliability with which the identifier is known. This attribute may be used to assist with identifier matching algorithms. The reliability attribute may take one of the following values:
Domain IdentifierReliability
| ISS | Issued by system | The identifier was issued by the system responsible for constructing the instance. |
| VRF | Verified by system | The identifier was not issued by the system responsible for constructing the instance, but the system that captured the id has verified the identifier with the issuing authority. |
| USE | Used by system | The identifier was provided to the system that constructed the instance, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user. |
Attribute Scope
Scope : CS
Specifies the scope in which the identifier applies to the object with which it is associated
Domain IdentifierScope
| BUSN | Business Identifier | An identifier that is associated with the object due to the business practices associated with the object. The scope of the use of the id may not be restricted to a single object, but may be reused for other objects closely associated with the object due to business practice. |
| OBJ | Object Identifier | The identifier associated with a particular object. It remains consistent as the object undergoes state transitions.
|
| VER | Version Identifier | An identifier that references a particular object as it existed at a given point in time.
The identifier can be considered an identifier of a static snapshot of the object. The identifier changes with each state transition on the object. I.e. The version identifier of an object prior to a 'suspend' state transition is distinct from the identifier of the object after the state transition. Each version identifier can be tied to exactly one ControlAct event which brought that version into being (though the control act may never be instantiated). NOTE: Applications that do not support versioning of objects must ignore and not persist these ids to avoid confusion resulting from leaving the same identifier on an object that undergoes changes |
| VW | View Specific Identifier | An identifier for a particular snapshot of a version of the object.
This identifies a view of the business object at a particular point in time, and as such identifies a set of data items that can be digitally signed and/or attested. This is in contrast to the Version Identifier which identifies the object at a specific time, but not the amount of information being asserted about the object. This identifier would be changed when a transformation of the information is performed (eg to add code translations, to provide a simplified textual rendering, or to provide additional information about the object as it existed at the specific point in time). |
Resolution
Passed INM 30/4/2007: Motion to add use code called use to the II datatype
Taskforce Vote: We approve the domain defined here and will advance this for harmonization.
For: Grahame, Lloyd, Lee (hesitantly -- see above) Against: Gunther, I move to continue discussion. Gschadow 09:42, 19 May 2007 (CDT) Abstain
Gunther's motion was accepted, and discussion continued. This led to a revised decision to have two attributes, scope and reliability.
Taskforce Vote: We approve the two attributes defined above and will advance their domains for harmonization.
For: Grahame, Lee Against: Abstain
Note: The use cases relating to reference have been pushed into updateMode.
Original proposal
| ISS | Issued by system | The identifier was issued by the organisation identified as the scoper of the role on which the id appears. May only be used on Role identifiers. Mutually exclusive with Used and Verified.
The identifier was issued by the system responsible for constructing the instance. Mutually exclusive with Used and Verified.
|
| VRF | Verified by system | The identifier was not issued by the organisation identified as the scoper of the role on which the id appears, but the system or user that captured the id has verified the identifier with the issuing authority. May only be used on Role identifiers. Mutually exclusive with Issued and Used.
The identifier was not issued by the system responsible for constructing the instance, but the system that captured the id has verified the identifier with the issuing authority. Mutually exclusive with Issued and Used.
|
| USE | Used by system | The identifier was provided to the organisation identified as the scoper of the role on which the identifier appears, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user. May only be used on Role identifiers. Mutually exclusive with Issued and Verified.
The identifier was provided to the system that constructed the instance, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user. Mutually exclusive with Issued and Verified.
Gschadow 13:04, 20 May 2007 (CDT) |
| NPLY | Role id | The identifier applies to the role itself, rather than a specific player in the role. I.e. The id applies to the role, regardless of who is playing it. Only applies to Roles.
|
| RW | Real World Identifier | This represents a potentially non-reliable identifier communicated for business purposes, but not deemed appropriate for matching purposes.
|
| BUS | Business Identifier | This is a commonly used identifier associated with a particular object. It is often a publicly exposed identifier which is known to providers and may be printed on reports or forms. It remains consistent as a class undergoes state transitions, including suspend, resume, revise, abort and complete. It is the truest identifier of the "object", given the MnM paradigm that an object persists across state transitions.
|
| VER | Version Identifier | This is a type of identifier introduced in some jurisdictions to allow referencing a particular business object as it existed at a given point in time. They can be considered identifiers of a static snapshot of the object. This type of identifier changes with each state transition on the object. I.e. The version identifier of an object prior to a 'suspend' state transition is distinct from the identifier of the object after the state transition. Each version identifier can be tied to exactly one ControlAct event which brought that version into being. NOTE: Applications that do not support versioning of objects must ignore and not persist these ids to avoid confusion resulting from leaving the same identifier on an object that undergoes changes
|
| VW | View Specific Identifier | This is an identifier for the exact information items that are included within a static model instance. This identifies a view of the business object at a particular point in time, and as such identifies a set of data items that can be digitally signed and/or attested. This is in contrast to the Version Identifier which identifies the object at a specific time, but not the amount of information being asserted about the object. This identifier would be changed when a transformation of the information is performed (eg to add code translations, to provide a simplified textual rendering, or to provide additional information about the object as it existed at the specific point in time). Note that the Information Instance Identifier may be conveyed with all its information items "byValue" or with none or some "byReference". These additional use codes allow Information Instance Identifiers to be used when only enough information for populating a picklist is needed, with the full inforomation instance being retreived if needed.
|
| REF | Reference | The identifier is being used in an object instantiation that is not self defining. The complete details are expected to be available from some other source, either another message, or a service, or database. Mutually exclusive with Definitional.
|
| DEF | Definition | The identifier is being used in an object instantiation that contains enough information to completely define the object described by the class. Mutually exclusive with Reference.
|
Discussion
Lloyd - should be called "use" not "useCode"
Lee - question on REF. I would expect that if I received a Reference, that would indicate that somewhere there is either a View, Version, or Definition identifier that matched it and I would not need to specify which it is on use.
Lee - As I think about this more, I believe REF is mutually exclusive of any other use. We also need to specify that use doesn't come into play when determining equivalence.
Lloyd - A reference could be to a view, a version or a business level id. It's reasonable for a reference to indicate what kind of reference it is. Not sure what you mean by "doesn't come into play when determining equivalence"
Lee - I'm uncomfortable with the role related uses above, though I'll still vote in favor (we can deprecate them later)
Lloyd - Can you further explain your discomfort. (Definitely not interested in adding something we think we might want to deprecate . . .)
- Lee - The Role related uses are essentially being used to define the relationship of the id to other RIM objects, in my opinion this should be explicitly modeled in the RIM rather than implied through data types. I.e., if we want to state that the Id was issued by the scoper there should be a participation to an Id issuing act with the issuer as another participant of that act. There may be situations where you wan't to define who issued the Id, and it isn't the scoper, this mechanism will support that while the use codes would not.
Gunther - I am too hesitant to vote in favor. I think this is too big a change to go so fast. I want to see use cases for each one of these. And the definitions need serious cleanup. This is such a fundamental thing, if it is screwed up all hell breaks loose. I am making detail comments above, because that's the only way to resolve these. Gschadow 09:41, 19 May 2007 (CDT)
To summarize my negative vote is because (1) some things don't belong in II data type, (2) others need much better technical definition (how exactly I have to implement this), and (3) some are not about identifiers, nor about the objects that own them. Gschadow 10:24, 19 May 2007 (CDT)
Lloyd: Use-cases:
The different role id types differentiate how the id relates to the scoper. For role ids, the id is generally one used by the scoper to identify the player. However, it's often useful to know who actually issued an id and also the level of confidence held in that identifier because that affects how much the recipient will trust it for doing matching within their own system. Also, sometimes we want to identify a role independent of player.
Business id - used to query an object independent of what changes may have happened to it over time. Usually the level at which objects are linked. E.g. A lab result would reference the order it's fulfilling by business id.
Version id - used to identify what version you've seen. Can be used to manage collisions when performing updates. E.g. When querying the details of an object, you get the version id of the version you're seeing. When you submit an update, you submit the id of the version you want to update. If that doesn't match the current version, your update doesn't go through. Also used when chaining back through historical views of an object when a query response includes object history.
View id - used to indicate exactly what's being attested. Particularly useful when doing references from other instances. "I made this decision on this particular view of this particular version of this object".
Reference - Allows you to say that you're not providing the details here, merely providing a reference to something defined elsewhere that you need to retrieve if you want the full story.
Definition - I'm giving you the full story.
Links
Back to Data Types R2 issues
Notes
From Rik:
Yes, but a reference to an act isnt the same as an act.
I think there is a clear distinction between an act (that has some id) and a reference to that act. And I think this is independent of any update semantics, ie. whether or not that act would have the same id if it was changed and re-messaged.
Clinical Statement has acts in the choice box, and it has ActReference, which is a pointer-to-act. Since HL7 doesn't directly support this pointer concept, ActReference is modelled as a cut down act. The only way to know that it is a reference rather than a act is to recognise that it hasn't enough attributes to be anything else, or to use its clone name (or its act relationship clone name).
Neither of these is good practice or foolproof. But they are at least signs that allow your code to do the lookup, rather than try to cope with an act that has nothing in it.
So I don't think the ActReference construct is just a convenience. Its a distinct construct that unfortunately looks a lot like an act, due to limits of the machinery.
The proper way to do references will indeed be via II.useCode (wiki about this is at http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_57 <http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_57> ), which could eventually be applied to either the main CDA act choice or to ExternalActChoice.
Since it isn't in CDA R2 datatypes I don't think this is a permissible realm extension, but I'm not certain. But even if it is we still need to resolve the typeCode, inversionInd or act.code issues. So its back in the CFH court to work this through I reckon.
- A reference construct is not needed at all. What we do in Java SIG code is reconcile with database objects immediately was we parse. Every external representation of an object (with id) is both reference to something already know and new information to be added. The detail of this is a matter of "update mode". However, there is no need for a reference vs. definition distinction. It is not so clear cut anyway. Gschadow 10:27, 19 May 2007 (CDT)
Skype threads
Id specific to a role
[1:49:41 PM] Gunther Schadow says: Lloyd, id for the Role alone is something that requires more work. I'm not against anything that's right, but how can we explain that? What is a Role instance for us in HL7? Is it something that is forever tied to a player and scoper or not? It needs to be carefully explained and considered what people are to do when implementing this. [1:51:15 PM] Grahame Grieve says: Gunther and I have discussed this before; a classic use case is a condition that the admitting officer approve a treatment. It doesn't matter who that is. I think that this is flaw in the RIM conceptualisation itself, and putting a band-aid solution of a property on the id is not going to solve the problem [1:52:34 PM] Gunther Schadow says: What is it exactly that needs to be fixed? [1:55:24 PM] Lloyd McKenzie says: Sometimes when people identify a role, they're identifying the role alone, as opposed to the role as it applies to a particular player. Usually the id applies to the player of the role. However, in this case, it applies to the role alone [1:57:01 PM] Gunther Schadow says: A Role alone without a player isn't that a Role type? A Role class? A definition of a Role? Like a Role with a KIND Entity playing it? [1:57:28 PM] Gunther Schadow says: That Role is still a different Instance than the one played by Joe Smith. [1:57:53 PM] Gunther Schadow says: And when John Walton takes Jioe's role, it becomes a new instance. [1:58:00 PM] Gunther Schadow says: with new id. [1:58:13 PM] Grahame Grieve says: what if you don't know which entity has the role? [1:58:23 PM] Lloyd McKenzie says: Agree [1:58:29 PM] Grahame Grieve says: You know that some entity will play the role, but you don't care. [1:58:39 PM] Grahame Grieve says: but you can still describe the role [1:59:10 PM] Gunther Schadow says: Then you leave the role unidentified? If you don't know the Entity, you do not know the Role instance fully. All you have is a description, but no identification. [1:59:40 PM] Lloyd McKenzie says: A role exists as a type and can have an id [2:00:04 PM] Gunther Schadow says: That still doesn't make a case for John taking over Joe's Role instance. [2:00:28 PM] Gunther Schadow says: You can have as many ids on a Role as you like, but when the player changes, it's a different Role. [2:01:19 PM] Lloyd McKenzie says: That's not what we're talking about. John and Joe would be playing different role instances [2:02:09 PM] Gunther Schadow says: So, what does this II use code contribute? [2:04:08 PM] Lloyd McKenzie says: The definition for id says it applies to the player. [2:04:15 PM] Lloyd McKenzie says: In this case, it does not [2:12:32 PM] Gunther Schadow says: But it still does. It is the id of the Role. But the role is unique to the player. [2:13:20 PM] Lloyd McKenzie says: There *isn't* a player in this situation [2:13:30 PM] Gunther Schadow says: The point of saying the id applies to the player is to make sure people don't say it applies to the scoper (e.g. so that they don't use the Employment.id to put the employer id there.) [2:13:40 PM] Lloyd McKenzie says: And it doesn't say "unique to the player". It says it identifies the player [2:13:57 PM] Gunther Schadow says: If there isn't a player, the id still applies to the Role. What is the problem? [2:14:09 PM] Gunther Schadow says: Then that needs to be fixed. [2:17:41 PM] Gunther Schadow says: BTW, it still identifies the player (if there was one). And also, there is always a player, you might not know much about the player, but there is one. And if there is one, the Role id does identify that player also. So it's not wrong. [2:19:06 PM] Lloyd McKenzie says: If you're just identifying the role, there is NO player. I'm just talking about the role, not anything else [2:23:15 PM] Gunther Schadow says: That is not possible in our model, and neither in the world. Even if you talk about a Role as KIND, you do that with a player as KIND. [2:23:32 PM] Gunther Schadow says: When I say not possible, I mean unnecessary complication. Not needed. [2:23:49 PM] Gunther Schadow says: Use case? (real world please) [2:25:49 PM] Lloyd McKenzie says: I don't need it. My understanding is effectively Role master-files [2:26:44 PM] Gunther Schadow says: Role master files don't need it either. They will have a player Entity in KIND determiner. Something that says what might possibly fill that Role. [2:26:54 PM] Grahame Grieve says: Condition of action by someone playing the role. Record of someone having done something, but the person is unknown. [2:27:04 PM] Grahame Grieve says: I expect you to argue with the second [2:27:19 PM] Grahame Grieve says: but the point is, there is always an entity playing the role, but sometimes you may not know or care who [2:27:46 PM] Grahame Grieve says: but whatever, I cannot think that these cases are properly dealt with by putting some flag on the properties of an id [2:29:06 PM] Gunther Schadow says: I don't understand what a "Condition of action by someone playing the role" is? Just because you may not know the Entity playing doesn't mean there is none, doesn't mean you won't have anything to say about it. You know the murderer was male and in his 40s, even if you can't identify him. [2:29:30 PM] Lloyd McKenzie says: But we're not talking about an instance. [2:29:35 PM] Gunther Schadow says: Lloyd says "I don't need it." then who does? [2:29:46 PM] Gunther Schadow says: Else, we can strike it. [2:29:54 PM] Lloyd McKenzie says: We're not talking about "a vice president". We're talking about "vice presidents in general" [2:30:22 PM] Grahame Grieve says: I specify a condition on a procedure, and the condition is that the senior medical officer approves the procedure at the time [2:30:27 PM] Gunther Schadow says: Vice president in General is still a Role and the player must be a human being, no? [2:30:31 PM] Grahame Grieve says: is this a reasonable use case? [2:31:00 PM] Gunther Schadow says: The senior medical official might be a dor or a manufactured shoe? [2:31:12 PM] Gunther Schadow says: dor or dog I mean? [2:31:21 PM] Lloyd McKenzie says: But we'renot ientifying the entity kind in the role, we're identifying the role. [2:31:27 PM] Grahame Grieve says: no, it will be a person. usually, though with some I have known it's not obvious ;) [2:31:41 PM] Grahame Grieve says: but we don't know which of the possible list of persons it could be, nor do we care. [2:31:48 PM] Lloyd McKenzie says: Like I say, it's not my use-case, merely reflecting the use-case as I unerstand it. [2:31:56 PM] Gunther Schadow says: Right, therefore there will be an Entity (KIND) on the player side. [2:32:10 PM] Gunther Schadow says: So whose request is it? [2:32:25 PM] Grahame Grieve says: ok, there's an entity kind. It's kind of a hanging stub of uselessness, but that's ok [2:32:35 PM] Grahame Grieve says: what actually identifies this thing as the SMO? [2:32:44 PM] Gunther Schadow says: SMO ??? [2:33:00 PM] Grahame Grieve says: smo = senioer medical officer - a common term in Aus [2:34:06 PM] Gunther Schadow says: The other Roles (credentials) associated with that ... dare I say ... Kind of Entity playing the role. The epitome of uselessness :x [2:34:59 PM] Grahame Grieve says: escalation; I didn't call it the epitome. just the hanging stub. [2:35:27 PM] Gunther Schadow says: (whew) [2:35:32 PM] Grahame Grieve says: but I don't understand your answer - in terms of how I know the role itself it being identified [2:36:03 PM] Gunther Schadow says: What is identified is not the Role itself. There is no Role ever even thinkablke without a player. [2:36:38 PM] Grahame Grieve says: so, how do I say, the SMO must do this? [2:36:39 PM] Gunther Schadow says: If you think SMO, you know human. So, identify the Role, you identify the entire cluster of Role + Player. [2:36:55 PM] Grahame Grieve says: Player is a entity kind of human, with no id. [2:37:12 PM] Grahame Grieve says: so all I have to go on is a role code, no id on the role? [2:37:36 PM] Grahame Grieve says: and I'd have to infer from logic whether a particular role/entity combo met the condition? [2:37:44 PM] Gunther Schadow says: By doing exactly the same as if you knew the SMO's name and personal id, then remove the name and change the id into something else. [2:38:32 PM] Gunther Schadow says: Yes? [2:39:12 PM] Grahame Grieve says: I'd rather have an id myself. but I guess it's a solution of sorts. Lloyd? [2:39:32 PM] Gunther Schadow says: You can have an id for this. [2:39:44 PM] Gunther Schadow says: It is O.K. to give an id to that Role. [2:40:06 PM] Gunther Schadow says: You identify the fictitious placeholder for a Role+Player complex. [2:40:18 PM] Lloyd McKenzie says: And the challenge is that the definition says that it's for the player and not the role [2:40:43 PM] Gunther Schadow says: And it is. The SMO is a person after all, even if just the thought of any SMO. [2:40:55 PM] Gunther Schadow says: No Role without player. [2:41:41 PM] Gunther Schadow says: That's why we usually name Roles by the name of the player (in common English, not just HL7venese).
Long rambling thread about II, alabama, and the universe
[5/22/2007 9:05:38 PM] Grahame Grieve says: Charlie, I am leaning towards proposing that we toast DEF/REF in II.use. would you like to speak in their defence? [5/22/2007 9:06:22 PM] Grahame Grieve says: I have made updates to issue 57 again. I would like to toast: NPLY, RW, REF and DEF [5/22/2007 9:06:51 PM] Grahame Grieve says: this would leave us with ISS, VRF, USE and BUS, VER, VW [5/22/2007 9:07:35 PM] Grahame Grieve says: two different axes. Frank Oemig has been hassling me today that things like this should be two different properties, not a single multi-axial set. What has the justification for that approach in the first place (say, AD.use) [5/22/2007 9:08:21 PM] Grahame Grieve says: I have provided new definitions for ISS, VRF, USE - in the table, but down below the existing definitions that Lloyd proposed and the comments from Lloyd and Gunther. [2:40:00 AM] Lee Coller says: How about we just keep BUS, VER, and VW and defer on the reset. Frank has a good point that these are on different axes. I"m a little uncomfortable dropping REF without another mechanism for specifying that this ID is supposed to reference something that you should already know about. This issue has arisen in other committees, the idea that its a reference if you already have the object isn't satisfying to many (I might want to flag an error or tell you if you send me a reference and I don't have the underlying object). [2:41:45 AM] Gunther Schadow says: "dropping REF without another mechanism for specifying that this ID is supposed to reference something that you should already know about." ... this is what update mode is for. [2:41:49 AM] Gunther Schadow says: But consider this: [2:42:03 AM] Gunther Schadow says: data types without RIM. Where would you use them ... [2:42:12 AM] Gunther Schadow says: procedure call, for example. Then [2:42:13 AM] Lloyd McKenzie says: UpdateMode doesn't tell you anything about that. [2:42:25 AM] Gunther Schadow says: Sure it does. [2:42:25 AM] Lloyd McKenzie says: UpdateMode just says "add, change, remove" [2:42:36 AM] Gunther Schadow says: Look at MDF 99. [2:42:38 AM] Lee Coller says: How, a reference isn't changing anything? [2:42:53 AM] Lloyd McKenzie says: MDF 99 is long superseded [2:42:57 AM] Gunther Schadow says: The point is, it is not a property of the ID whether you use it for reference or not. [2:43:04 AM] Lloyd McKenzie says: UpdateMode only tells you add, change, remove. [2:43:27 AM] Lloyd McKenzie says: Is it a property of a phone number whether you use it for home or work? [2:43:27 AM] Gunther Schadow says: Just as it is not a property of a primary key attribute in a database. It is used for both, of course! [2:43:52 AM] Lloyd McKenzie says: I'm not sure I see a distinction between the use-cases . . . [2:43:53 AM] Gunther Schadow says: But MDF 99 is the only real analysis & design of update mode. It's not to be forgotten. [2:44:02 AM] Lloyd McKenzie says: It is completely superseded [2:44:12 AM] Lloyd McKenzie says: It was replaced by the paper on updateMode in the HDF. [2:44:29 AM] Lee Coller says: I could argue that none of these are properties of an ID. What I had called the "Role Related" items are in fact proerties of the ID in relationship to something else, and the "BUS/VW/VER" properties relate to what the ID refers to. [2:44:29 AM] Gunther Schadow says: Then that HDF paper is incomplete :) [2:44:30 AM] Lloyd McKenzie says: Because no-one understood how the MDF 99 codes should actually have been used [2:45:24 AM] Gunther Schadow says: "Is it a property of a phone number whether you use it for home or work?" yes, the phone number is an address for a communication service and the phone next to me is a business phone. [2:45:53 AM] Gunther Schadow says: "Because no-one understood how the MDF 99 codes should actually have been used" tough, should have thought harder... Now we have to think it here anyway :) [2:45:59 AM] Lloyd McKenzie says: My cell could be a business phone or a home phone or both and I might change how it's used. [2:46:18 AM] Lloyd McKenzie says: Similarly, an id can be used in different ways - same id, same phone number [2:46:39 AM] Gunther Schadow says: But a phone number is a service address, and if you give me that service endpoint, you can tell me if it's home of business use. [2:46:55 AM] Gunther Schadow says: But if you give me an id, it is never DEF or REF, it is always both! [2:47:14 AM] Gunther Schadow says: Just like a phone number is never DEF or REF, it is always both, else it would be useless. [2:48:44 AM] Lloyd McKenzie says: Ok, so how is ref supposed to work with updateMode? [2:52:16 AM] Gunther Schadow says: You send me an id, and you can say whether one of the following is true:
1) use it as a Key (K) 2) use it for validation (V) 3) use it just as data (add A or update E) 4) ignore it (I)
This, info belongs to the transaction, it is not a property of the value. [2:52:38 AM] Gunther Schadow says: That's how the original update mode is defined. [2:53:32 AM] Lloyd McKenzie says: So "key" is "reference"? [2:54:17 AM] Gunther Schadow says: Yes, key means, use as primary key. But as Grahame said earlier, and I agree, in many cases the K, V, and A/E is in the eye of the beholder. [2:54:24 AM] Gunther Schadow says: *sometimes. [2:57:39 AM] Lee Coller says: Are you saying I'd only use "K" if I wanted to reference something you should already know about -- In other words, I'd never use it if my intent was to specify the object? [3:06:34 AM] Gunther Schadow says: Yes, because in an unforgiving implementation K would cause a look-up and if it wasn't found, we would have an exception. Similar to V. [3:06:48 AM] Gunther Schadow says: However [3:07:36 AM] Gunther Schadow says: If your intent is to "INSERT OR UPDATE" then a variant of K would be used, let's call it Ki for a moment. [3:07:56 AM] Gunther Schadow says: OTOH could also say that depends on the context. [3:08:33 AM] Charlie McCay says: the usecase for K that I care about update would not be relevant -- it is only for references to "view" identifiers -- where the set of information items is referenced [3:08:40 AM] Gunther Schadow says: The update mode would be on the parent element too, so, if the intent is to insert or update (A or E) an object and I send you an id marked a K then it means Ki. [3:08:53 AM] Charlie McCay says: ie where if you have something to point to, then you have everything [3:09:34 AM] Gunther Schadow says: That only works inside a single message, Charlie, is that what you want? [3:10:32 AM] Charlie McCay says: no -- I want to send identifiers for a "view" of an act (as expressed in a clinical statement) -- and be able to send a reference to is [3:11:18 AM] Gunther Schadow says: That is then a VW id, right? It has nothing to do with the REF/DEF discussion. [3:11:49 AM] Charlie McCay says: ok -- I will back out and read the thread properly...apologies [3:12:08 AM] Gunther Schadow says: If I store views in a database (which I personally don't do), then the issue would still be dealt with K. [3:13:09 AM] Charlie McCay says: That sounds correct -- if this usage of updateMode is confirmed / adopted [3:14:52 AM] Charlie McCay says: I do tend to agree that K / Ref makes less sense outside views [8:29:21 AM] Lloyd McKenzie says: View and reference aren't the same. You could have a definitional view or a reference to a view and need to be able to tell the difference. [8:30:30 AM] Gunther Schadow says: noone says that "view and reference are the same". [8:31:15 AM] Lloyd McKenzie says: That's how I interpreted this: [8:31:16 AM] Lloyd McKenzie says: [11:10:41 AM] Charlie McCay says: no -- I want to send identifiers for a "view" of an act (as expressed in a clinical statement) -- and be able to send a reference to is [11:11:26 AM] Gunther Schadow says: That is then a VW id, right? It has nothing to do with the REF/DEF discussion. [8:44:21 AM] Gunther Schadow says: What I said there was that view and reference aren't the same, I meant they are orthogonal issues and the K-key thing discussed above is applicable for VW or not VW just the same. [9:05:58 AM] Grahame Grieve says: I agree with Gunther. [9:06:21 AM] Lloyd McKenzie says: I'm ok with that too [9:06:35 AM] Grahame Grieve says: why don't we have separate properties for the different kind of uses? Mainly I'm asking about EN and AD, though obviously the point is relevant here [9:07:06 AM] Grahame Grieve says: I mean I agree with Gunther more generally - it is not a property of an ID whether the object that contains is used as a ref or a def [9:08:57 AM] Grahame Grieve says: in fact, I suspect the whole ref/def use case. I'm not familiar with it as a concept in v2 at all - you take what you are given and merge it with what you have. If the outcome is not enough, you have an error condition. How can REF/DEF make any difference at all? [9:09:54 AM] Gunther Schadow says: In EN and AD it was felt that it was too messy to sort it out, I guess. Use codes in AD and EN do not control any action other than picking the one that fits. And so, the implementation of this would have been as a simple bitset where the presence of the code in the set sets the bit. Then to find an address that fits one goes in with two masks, one with the flags you want the other with the flags you do not want and that's how you pick your name or address to use. EN and AD use codes were never meant to control different behavior for each name (like store one but throw away the other, search with one this way and with the other that way, etc.) [9:10:55 AM] Grahame Grieve says: so do we have a problem with EN and AD - scope creep? [9:11:03 AM] Gunther Schadow says: I agree with Grahame on the v2 analog. [9:11:14 AM] Gunther Schadow says: Which ones are the creepers? [9:12:22 AM] Lee Coller says: Which one's aren't (I think its a shorter list) [9:20:17 AM] Grahame Grieve says: on AD: BAD (But Ithink this is a bad code anyway), so this is a short list [9:38:19 AM] Grahame Grieve says: SRCH, PHON, SNDX on EN [9:38:36 AM] Grahame Grieve says: I wonder about ABC, SYL, and IDE [9:38:44 AM] Grahame Grieve says: on both [9:41:37 AM] Lee Coller says: I thought we got rid of SRCH, SNDX on EN. Not sure about PHON [9:47:21 AM] Grahame Grieve says: I don't know anything about getting rid of them [9:47:41 AM] Lee Coller says: I recall a discussion at a past WGM, perhaps Boca? [9:53:01 AM] Lee Coller says: It was San Diego, just to remove SRCH. [9:53:19 AM] Lee Coller says: Motion -- Remove the SRCH use code from the EN datatype (Mark Tucker/Lee ??) 9-0-0 [9:53:39 AM] Lee Coller says: Comment -- There is no use case for 'storing' names/addresses with a SRCH use-code, as it is query specific. [9:53:45 AM] Grahame Grieve says: was there a harmonisation proposal? [9:54:32 AM] Lee Coller says: According to the Minutes it was Rene's action item. Probably fell through the cracks. [9:56:58 AM] Grahame Grieve says: Relevant INM action items:
add PHON as a use code to the AD datatype, datatypes.
* ?, 2007019 new
o SRCH was removed from the use-code of the EN datatype by motion. (Note that the DRAFT minutes erroneously state that SRCH needs to be added. This should be PHON)
Reorganize entityNameUse vocab, datatypes
* ?, 2007019 new
o With respect to SRCH/PHON and child concepts. Some of the specializations will have to be retained.
[10:02:25 AM] Lee Coller says: Looking at the March Harmonization Proposals I don't see anything. [10:42:47 AM] Gunther Schadow says: I never believed in PHON or SNDX etc. because there is no need to sending these or storing them. You can create a soundex, NYSIIS etc. strings out of any name part, and there is no need storing them. (Except if for indexing in a database.) [10:43:19 AM] Grahame Grieve says: but you still need to say this in a query [10:43:31 AM] Lloyd McKenzie says: Exactly, and that's what they're for. [10:43:40 AM] Grahame Grieve says: so, where do you say it? [10:43:44 AM] Lloyd McKenzie says: In theory, they're also useful when sharing masterfiles [10:43:56 AM] Lloyd McKenzie says: In registry queries [10:44:56 AM] Gunther Schadow says: ABC, SYL, and IDE are Japan/China/Korea (CJK) specific, and ABC could work for South Asian languages but not really, because SYL and IDE does not apply there. However, be they as specific to CJK as they may, they are use code in that you pick them from the bag depending on what you can pr want to display or print. [10:45:40 AM] Grahame Grieve says: but they are mutually incompatible no? so it would be useful if they were in a different attribute? [10:46:09 AM] Grahame Grieve says: and where do you say PHON, SNDX, etc, if not in the datatype? [10:46:10 AM] Gunther Schadow says: I don't think you ever need to say Soundex in a query. You will give me a name, and I, the MPI will do with it as I see fit. [10:46:47 AM] Lloyd McKenzie says: For Soundex, that's true. For phonetic, not true. [10:46:54 AM] Lloyd McKenzie says: For soundex, the only use-case is masterfile sharing [10:47:04 AM] Gunther Schadow says: Not even there. [10:47:13 AM] Lloyd McKenzie says: Why? [10:47:22 AM] Gunther Schadow says: It's simply pointless to store a soundex code. [10:47:33 AM] Lloyd McKenzie says: People store them all the time. [10:47:35 AM] Gunther Schadow says: Because you can always easily recreate it from the string. [10:47:43 AM] Lloyd McKenzie says: But it requires complex processing to do so [10:47:45 AM] Grahame Grieve says: why? What if you are obliged to store the query you were sent? [10:47:46 AM] Gunther Schadow says: People do pointless things :) [10:47:52 AM] Lloyd McKenzie says: And few systems want to do so at runtime [10:47:54 AM] Gunther Schadow says: Soundex is not complex. [10:49:49 AM] Gunther Schadow says: The query should not contain soundex. Noone is supposed to type in soundex. [10:50:04 AM] Grahame Grieve says: who said someone typed it in? [10:50:07 AM] Gunther Schadow says: The query should contain the original string as best as the user can figure it out. [10:50:13 AM] Gunther Schadow says: Who sends a query? [10:50:33 AM] Grahame Grieve says: See, Gunther, the problem is that you reject the use case, not the implementation [10:50:44 AM] Gunther Schadow says: What use case? [10:51:49 AM] Gunther Schadow says: I do reject the illusion of a use case unless I am convinced otherwise. But I am not fighting this with much effort, so you just do what you like here. [10:53:01 AM] Grahame Grieve says: that's not an offer you make often ;). I don't want to do anything, frankly. I think they'd be better separate, but it's not worth changing. Back to II. My feeling now is that we should reject II.use, and have 2 properties: reliability (ISS, VRF, USE) and scope (BUS, VER, VW) [10:54:00 AM] Gunther Schadow says: I am still concerned about ISS VRF USE. But BUS, VER, VW is lacking a 4rth code, which is "AISTB" [10:54:07 AM] Lee Coller says: II.reliability and II.scope? [10:54:22 AM] Grahame Grieve says: the second could equally be achieved by toasting all the id properties in the rim, and replacing them with 3 properties (businessId, versionId, and viewId), all SET<II> [10:54:27 AM] Grahame Grieve says: AISTB is? [10:54:41 AM] Gunther Schadow says: As It's Supposed To Be (used) [10:55:34 AM] Grahame Grieve says: how about HIWTUI (However I Want To Use It) [10:56:36 AM] Gunther Schadow says: meaning, an HL7 RIM object with the scope/extent as it is supposed to be. I.e., the id stands for the object, and views and versions make no new object and edits after object is active or completed are done in new objects superceding the old ones. [10:57:40 AM] Grahame Grieve says: well, this is reasonably close to the BUS identifier - no? Just an adjustment of the definition? [10:57:52 AM] Gunther Schadow says: No, BUS is different. [10:58:42 AM] Gunther Schadow says: If I were in charge, I would only allow BUS as a special flag, meaning: this id has a scope larger than HL7 semantics want it. Someone, for instance, used the same "order id" for its filler intent and the result report. [10:58:58 AM] Gunther Schadow says: I mean, for its order confirmation and its result report. [10:59:07 AM] Gunther Schadow says: A typical HL7 v2 filler order id is like that. [10:59:19 AM] Lloyd McKenzie says: Fundamentally, I don't care about sound-ex. I care about PHON. SoundEx was added by friendly amendment [10:59:36 AM] Gunther Schadow says: How does PHON work? [11:00:22 AM] Grahame Grieve says: using the same id for order confirmation and result report is just reusing an identifier. [11:00:33 AM] Lloyd McKenzie says: BUS is no different [11:00:37 AM] Lloyd McKenzie says: It's one object [11:00:43 AM] Gunther Schadow says: no [11:00:47 AM] Lloyd McKenzie says: The problem is that in your world, only one person's allowed to update the object [11:00:59 AM] Gunther Schadow says: it's one object in your system, but often more than one in HL7 RIM semantics. [11:01:01 AM] Lloyd McKenzie says: In my world, anyone in the province can update the object [11:01:11 AM] Gunther Schadow says: But that's wrong. [11:01:18 AM] Lloyd McKenzie says: Why is it wrong? [11:01:30 AM] Lloyd McKenzie says: gtg [11:01:49 AM] Gunther Schadow says: Because the RIM was designed so that you make revision objects if people want to change things. [11:01:51 AM] Grahame Grieve says: I don't see how Lloyds original definition "This is a commonly used identifier associated with a particular object. It is often a publicly exposed identifier which is known to providers and may be printed on reports or forms. It remains consistent as a class undergoes state transitions, including suspend, resume, revise, abort and complete. It is the truest identifier of the "object", given the MnM paradigm that an object persists across state transition" is any different From Gunthers AISTB [11:02:22 AM] Gunther Schadow says: It is very different. Lloyd and I could not agree less on anything else. [11:02:52 AM] Gunther Schadow says: In HL7 v3 as we have designed in (with much committee discussion) [11:03:13 AM] Gunther Schadow says: an HL7 v2 filler-order are two different things. [11:03:25 AM] Gunther Schadow says: OBR as a "turn around segment" is 3 different things. [11:04:02 AM] Gunther Schadow says: 3 objects (at least): order as placed, filler confirmation (intent), filler event (report). [11:04:07 AM] Lee Coller says: I think Lloyd's definition is overly narrow. I'd rather simply have "This is an identifier associated with a particular object. It remains consitant as the object undergoes state transitions." [11:04:08 AM] Gunther Schadow says: 3 objects -> 3 ids. [11:04:21 AM] Grahame Grieve says: well, by class I presume he means instance of a class, but I still don't see that the definitions are different. agree that filler/order are different, but using the same identifier is irrelevant to the identifier, and I don't see how some flag on the id meaning "hey, I'm using this identifier in *some* enlarged scope is going to make any useful difference to anyone [11:04:43 AM] Lee Coller says: Notice I fixed that in my simplification [11:04:58 AM] Gunther Schadow says: " but using the same identifier is irrelevant to the identifier" [11:05:00 AM] Grahame Grieve says: I could go with Lee's definition - but how is this different to AISTB? [11:05:01 AM] Gunther Schadow says: no! [11:05:06 AM] Gunther Schadow says: It's not irrelevant! [11:05:22 AM] Gunther Schadow says: We talks about Act.id. It's a key. Perhaps a primary key. [11:05:27 AM] Gunther Schadow says: Can't reuse that. [11:06:12 AM] Grahame Grieve says: who says? if my report response is one to one with your order request, is it wrong for me to use the same id as a matter of convenience? [11:06:32 AM] Grahame Grieve says: actually, I should give it a different root, right? [11:06:38 AM] Gunther Schadow says: When I have activated an order or finalized a report, I am not supposed to make any further changes. Any change I make must be in a new object that supercedes the old object. [11:06:46 AM] Gunther Schadow says: New object, new id. [11:07:06 AM] Grahame Grieve says: so, Lee's definition for BUS should stand then, and we don't need AISTB [11:07:07 AM] Gunther Schadow says: Yes, it is very wrong to reuse it. [11:07:25 AM] Gunther Schadow says: No, AISTB is do not ever reuse. [11:07:33 AM] Grahame Grieve says: And I think you misread Lloyd's definition. Because it also means, do not ever reuse [11:07:38 AM] Gunther Schadow says: New object, new id. [11:07:48 AM] Gunther Schadow says: No. [11:07:57 AM] Gunther Schadow says: He reuses it all the time when he should make a new one. [11:08:10 AM] Lee Coller says: Gunther -- are you saying a state transition results in a new object? [11:08:11 AM] Gunther Schadow says: No change of active orders without new id. [11:08:30 AM] Gunther Schadow says: Sometimes of course. [11:08:31 AM] Grahame Grieve says: Don't care what Lloyd does. He's always doing his own silly thing. What's wrong with Lee's definition? [11:08:41 AM] Gunther Schadow says: Don't call Lloyd silly. [11:08:47 AM] Gunther Schadow says: He's not silly. [11:09:06 AM] Grahame Grieve says: no, never, but it's always fun to call him silly [11:09:22 AM] Gunther Schadow says: But it is very important to me to make sure that the HL7 RIM understanding of an object life cycle is not undermined, and Lloyd undermines it. [11:09:32 AM] Grahame Grieve says: I don't see why his definition undermines it [11:09:37 AM] Lee Coller says: I don't either [11:09:48 AM] Grahame Grieve says: and you still haven't said why not to use Lee's definition. [11:09:55 AM] Gunther Schadow says: Because he changes active orders without changing the id. [11:10:11 AM] Gunther Schadow says: Lloyd does, not Lee. [11:10:42 AM] Grahame Grieve says: I don't see that in the definition. In fact, it's irrelevant to the definition, but maybe worth documenting somewhere else - that object ids are supposed to be globally unique [11:10:59 AM] Gunther Schadow says: "This is an identifier associated with a particular object. It remains consitant as the object undergoes state transitions." this is not what Lloyd means. [11:11:26 AM] Grahame Grieve says: So, he doesn't say what he means, so therefore you have a problem with what he says? [11:11:33 AM] Grahame Grieve says: I don't see your issue [11:12:14 AM] Gunther Schadow says: You have taken BUS and cippled the definition to the point where it is indistinguishable from AISTB. [11:12:33 AM] Gunther Schadow says: Here is my use case for BUS as opposed to AISTB: [11:13:07 AM] Grahame Grieve says: how have we crippled the definition? I personally thought they were the same thing, I still can't see otherwise from the definition. You appear to be arguing based on Lloyd's own practise rather then the definition [11:14:17 AM] Gunther Schadow says: I have an HL7 v2 system which wants to slap its filler order id in, another its accession number, a 3rd its case number. They use that as a reference and they don't know really how to deal more precisely with objects in the different moods and states of revision, etc. So they put this id in, but knowing that it is an unsharp id, they tag it with "BUS". It's an alert, meaning "hey, don't take this id too literally as an object id"! [11:16:43 AM] Grahame Grieve says: that use case reminds me of an old PJ O'Rouke comment about alabama passing a low fining someone who assaults a descrator of the flag $20: [11:16:55 AM] Grahame Grieve says: it's pinning a sign saying "kick me" to the backside of the majesty of the law [11:18:07 AM] Gunther Schadow says: ? [11:18:16 AM] Gunther Schadow says: That use case is real. [11:18:18 AM] Grahame Grieve says: funny - laugh. ha ha [11:18:28 AM] Grahame Grieve says: I don't think that usage is within the intent of BUS by any reading of the definitions [11:18:47 AM] Grahame Grieve says: I think that BUS is intended to be AISTB, and that this use case is something else again - but worth a flag [11:18:59 AM] Gunther Schadow says: I don't think so. [11:19:26 AM] Grahame Grieve says: which bit are you don't thinking so? [11:19:30 AM] Gunther Schadow says: Think about it: why the word "business"? [11:19:41 AM] Gunther Schadow says: "business names" are unsystematic names [11:19:50 AM] Gunther Schadow says: "busienss ids" are unsystematic ids. [11:20:19 AM] Grahame Grieve says: ok happy to split "BUS" from it's definition, attach Lees definition to some other code, and come up with a wild and woolly definition for BUS [11:20:22 AM] Gunther Schadow says: The word "business" reveals a remnant of the original intent of this code. [11:20:31 AM] Lee Coller says: Let's call it something other than BUS, how about OBJ [11:20:40 AM] Grahame Grieve says: I like it. [11:20:48 AM] Gunther Schadow says: Yes, O.K. now OBJ == AISTB. [11:21:12 AM] Grahame Grieve says: ok, so would you like to come up with an unsharp definition for BUS? [11:21:35 AM] Gunther Schadow says: But give something to Lloyd so that he can change active orders, cuz he's building a legacy system from the start (punch) [11:21:40 AM] Lee Coller says: The O'Rouke def doesn't work? [11:21:58 AM] Lee Coller says: Good thing noone on this is from Alabama (though Patrick Loyd is close) [11:22:41 AM] Gunther Schadow says: The meaning of this O'Rouke Alabama thing escapes me. Sorry. [11:23:38 AM] Grahame Grieve says: using the ORourke definition s the definition for BUS is just too recursively funny [11:23:44 AM] Grahame Grieve says: never mind [11:24:58 AM] Lee Coller says: Maybe we need a new datatype MBUID (Might Be Unique Id) [11:26:05 AM] Lee Coller says: Seriously though, using Gunther's [non]use-case [11:26:37 AM] Lee Coller says: The business identifier is an identifier constructed using an arbitrary algorithm whose intent is to provide a unique identifier for an object but may not actually do so. [11:26:49 AM] Grahame Grieve says: I am updating the proposal now [11:29:04 AM] Gunther Schadow says: "The business identifier is an identifier constructed using an arbitrary algorithm whose intent is to provide a unique identifier for an object but may not actually do so." is too funny. [11:29:14 AM] Gunther Schadow says: I don't understand why you're joking about this. [11:29:33 AM] Gunther Schadow says: How do you think the majority of people will migrate from v2 to v3? [11:29:50 AM] Grahame Grieve says: painfully. really. [11:30:36 AM] Gunther Schadow says: Our medical record system doesn't even have ids for Observations, how in the world could we deal with the rule "no changes after completion" ... heck, we don't even know the status of these records. [11:35:54 AM] Grahame Grieve says: ok, so we need a serious definition for BUS. No joking around about the majesty of the RIM anymore. [11:36:58 AM] Gunther Schadow says: you're still joking. We can set it aside until we can see more clearly. Wait until Lloyd comes back online. [11:37:29 AM] Grahame Grieve says: no, I'm actually trying to work on a serious definition, one that doesn't allow too much leeway but introduces enough [11:37:55 AM] Lee Coller says: It seems that the whole point (seriously) is that the uniqueness of a BUS Id is in question [11:38:12 AM] Gunther Schadow says: Yes. And yet, I'd still wait for a reaction by Lloyd. [11:38:27 AM] Grahame Grieve says: yes and no. Seems to me that within a scope, it's unique, but it may not be unique within all scopes [11:38:47 AM] Gunther Schadow says: (BTW: are you Grahame and Lee in some stealth mode? Skype tells me you're offline and yet your are there?) [11:39:00 AM] Grahame Grieve says: my skype claims that I am online. and Lee [11:39:16 AM] Gunther Schadow says: O.K. never mind Skype. [11:39:55 AM] Grahame Grieve says: how about: [11:39:56 AM] Grahame Grieve says: An identifier that is associated with the object due to the business practices associated with the object. The scope of the use of the id may not be restricted to a single object, but may be reused for other objects closely associated with the object [11:40:39 AM] Grahame Grieve says: or maybe [11:40:46 AM] Grahame Grieve says: An identifier that is associated with the object due to the business practices associated with the object. The scope of the use of the id may not be restricted to a single object, but may be reused for other objects closely associated with the object due to business practice [11:40:55 AM] Grahame Grieve says: just add the last few words [11:47:19 AM] Gunther Schadow says: yes, quite well said. [11:47:37 AM] Lee Coller says: That looks fine to me. Its time for me to go (Pain and Torture appointment) [11:47:53 AM] Grahame Grieve says: ok thanks. I will update the proposal. [11:48:22 AM] Gunther Schadow says: I'll sign off too, if I can, need to do some workin. [11:49:09 AM] Grahame Grieve says: yes, actual work. how about that. [11:49:20 AM] Grahame Grieve says: http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_57#Domain_Definition [11:49:33 AM] Grahame Grieve says: I have updated this, I think, to keep up with the discussion on definitions. [11:50:35 AM] Grahame Grieve says: Still want to split the definition and have II.reliability and II.scope, since we have 2 axes of mutually incompatible sets of terms. but it seems that we are agreed on this - (though we haven't heard from Lloyd yet)
[12:12:45 PM] Lloyd McKenzie says: Fundamentally, when an order exists, you're authorized to fulfill. When the order is suspended, you're no longer authorized to fulfill. If you had two orders, then you could be authorized to fill under one and not under the other. In my world, if a provider creates an order and another fulfills it, the right to fulfill is removed. It doesn't matter what the original ordering provider thinks. If they want to allow fulfillment to occur under their original order, they must resume that order. Until that happens, there's no authorization to fulfill. The whole point of the act state machine is to allow changes to state for the same instance of the object. If you've got a new classCode or a new mood or any other structural attribute, you must have multiple instances. However, if I suspend and resume, it's the same instance (though different versions). And I'm fine with Lee's definition by the way. I'm also happy with the term OBJ. Because in my world, there is only one OBJect. The OBJect isn't created unless the central system says "ok", and you're not allowed to fulfill unless the central system says ok, and anyone in the province (with the necessary permissions) can supend or resume that OBJect. [12:13:34 PM] Grahame Grieve says: glad to have agreement. [12:13:38 PM] Lloyd McKenzie says: Sorry, "if a provider creates an order and another fulfills it" should say "and another suspends it" [12:14:33 PM] Lloyd McKenzie says: I don't like the definition given to business id by Grahame. I have no need for one id across multiple objects. [12:14:44 PM] Lloyd McKenzie says: And it's a *really* bad thing to do. [12:15:00 PM] Lloyd McKenzie says: All I want is Object id. [12:15:40 PM] Lloyd McKenzie says: If you have multiple objects that share an id, there should be a single object that contains the others. (E.g. a prescription contains both substanceAdmin and supply components) [12:18:12 PM] Grahame Grieve says: ah, I wondered whether I would regret saying that I was glad to have agreement [12:19:54 PM] Grahame Grieve says: Gunther's use case didn't involve the capacity to create single wrapping objects. I laughed at this case, but I think it's pretty real world. I do think that users are doing to use the II like that in some cases, and I think that the definition I wrote gives enough leeway without giving too much. Of course, I wrote it myself.... [12:20:31 PM] Lloyd McKenzie says: Fundamentally, when you query by id, you need to be guaranteed it resolves to exactly one thing [12:20:53 PM] Lloyd McKenzie says: The only way you can do that is if there's some single owning structure with that id. [12:21:20 PM] Lloyd McKenzie says: Anything else breaks the foundational principle of identifiers as globally unique ids, and without that we're royally screwed [12:21:40 PM] Grahame Grieve says: true and false. or perhaps I should say, may misleading. I never perform a global identifier query across my system - I always have some context, and all I care about is whether an identifier is unqiue in that context [12:22:08 PM] Lloyd McKenzie says: In my system, we allow global id queries [12:22:14 PM] Grahame Grieve says: and I think that you are taking a step further there. [12:22:27 PM] Lloyd McKenzie says: I pass in an id, and it gives me the lab order, allergy, referral or whatever associated with the id. [12:23:02 PM] Grahame Grieve says: good luck to you. You have a vested interest in not having scope creep, so a vested interest in allowing such id's to be properly marked. unless you live in a fantasy world where such screwing with identifiers won't happen [12:23:25 PM] Gunther Schadow says: It is hard to operationalize the meaning of "one thing" when it comes to acts. [12:23:42 PM] Grahame Grieve says: anyway, the point is that you are taking an extra step. We have said that identifiers must be unique. You are also saying, "and they can only be used with respect to one single RIM object". [12:24:12 PM] Lloyd McKenzie says: We've always said a given id resolves to a single object. That's the definition of unique. [12:24:19 PM] Grahame Grieve says: that second step is a problem, and I agree with Gunther - it's hard to operationalise, especially if the business practices are not redesigned for RIM compliance [12:24:27 PM] Grahame Grieve says: where have we said this? [12:24:55 PM] Lloyd McKenzie says: Certainly the definition of an OID is that it refers to one and only one object over its lifetime [12:24:57 PM] Grahame Grieve says: so I approve of BUS with the general scope of the definition we have. It's a let out, like OTH on CD [12:25:03 PM] Grahame Grieve says: where? [12:25:52 PM] Lloyd McKenzie says: (My wife isn't happy with you - I'm supposed to be packing :)) [12:26:06 PM] Gunther Schadow says: Vacation? [12:26:09 PM] Grahame Grieve says: The definition of II: [12:26:10 PM] Grahame Grieve says: An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. [12:26:26 PM] Grahame Grieve says: so it explicitly disagrees with you about the scope being for a single RIM object. [12:26:49 PM] Lloyd McKenzie says: It says a thing or object [12:26:56 PM] Grahame Grieve says: my apologies to your wife. She can commiserate with my wife, who hates skype more than anything else. And I don't think I'm going to help you go to Jasper [12:27:01 PM] Lloyd McKenzie says: In RIM-speak, what is a thing other than a class instance (i.e. object) [12:27:13 PM] Lloyd McKenzie says: :) [12:27:33 PM] Grahame Grieve says: I feel another quote from PJ coming up. [12:27:57 PM] Grahame Grieve says: or maybe not, I thought a second time. that one was a bit inflammatory. [12:28:01 PM] Grahame Grieve says: (unlike the last one) [12:28:42 PM] Grahame Grieve says: from the context of the RIM, perhaps this is true. But the definition of II is clearly not so limited - explicitly so, as identifying a RIM object is only part of it's functionality [12:29:00 PM] Lloyd McKenzie says: I don't care about II outside of the RIM [12:29:13 PM] Grahame Grieve says: so you may associate an identifier of a concept with a RIM object, without asserting that this is an identifier for the RIM object itself. Or do you think that this is wrong? [12:29:37 PM] Lloyd McKenzie says: If you really insist on doing warped things in CEN or something else, then I'll squeal a bit, but eventually allow them to shoot off whatever part of their anatomy they desire. [12:29:50 PM] Grahame Grieve says: don't see how this is relevant. [12:30:18 PM] Lloyd McKenzie says: Anything outside the RIM must be CEN or ISO, because for HL7, II only exists in the context of the RIM. [12:30:22 PM] Grahame Grieve says: do you think it's wrong to associate an identifier of a concept with a RIM object without asserting that this is an identifier for the object itself? [12:30:47 PM] Lloyd McKenzie says: Not following the distinction. Can you give a real-world example of the difference? [12:31:54 PM] Grahame Grieve says: putting a drivers licence id on a role. we're not claiming that no other object could not be associated with this drivers licence id [12:31:57 PM] Lloyd McKenzie says: Wiki definition for OID: "In computing, an object identifier or OID is an identifier used to name an object" [12:32:37 PM] Lloyd McKenzie says: Ahh. Yes, I see and agree there. Same id could appear on LicensedEntity and IdentifiedEntity roles [12:33:00 PM] Grahame Grieve says: so, we can have a reason to associate an id with more than one object. Clearly, it's not an OBJ id. [12:33:07 PM] Lloyd McKenzie says: Terrifying in some of its ramifications, but true. [12:33:07 PM] Grahame Grieve says: so we need a category for it [12:33:30 PM] Grahame Grieve says: happy now? [12:33:33 PM] Lloyd McKenzie says: Actually, it is an OBJ id for the LicensedEntity role, but not for the IdentifiedEntity role, I think. [12:33:49 PM] Lloyd McKenzie says: I can buy that. Can we use an abreviation other than BUS for it? [12:33:55 PM] Grahame Grieve says: but it's going to put on Patient, you know that [12:34:01 PM] Lloyd McKenzie says: (Canada has pre-adopted BUS for OBJ) [12:34:07 PM] Lloyd McKenzie says: I know. [12:34:11 PM] Grahame Grieve says: well, preadoption, you know.... [12:34:17 PM] Grahame Grieve says: want to propose something else? [12:34:40 PM] Lloyd McKenzie says: That's why I said "Can we" (with an implied 'pretty please') :) [12:35:31 PM] Lloyd McKenzie says: How about BUSN. Just something so it's different [12:35:44 PM] Lloyd McKenzie says: And I presume we're still adding OBJ? [12:35:55 PM] Grahame Grieve says: seems reasonable to me. yes, check the page.
