Datatypes R2 Issue 57

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

Domain Definition

This table was controversial.

The definition below was revised from the first proposed definition after extensive and exhausting discussion. The first proposal, with comments, is found below.

ISS	Issued by system	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 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 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.
BUS	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 consitant 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).

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. What is a "scoper" on an II? Gschadow 10:15, 19 May 2007 (CDT) It's a scoper for the role. --Lmckenzi 15:18, 19 May 2007 (CDT) I sorta guessed that. But my point was it doesn't seem right to speak about Role in the data type spec. At least not so matter-of-factly. Gschadow 13:04, 20 May 2007 (CDT) The identifier was issued by the system responsible for constructing the instance. Mutually exclusive with Used and Verified. The intent of this code is to provide assurance that the identifier is known to be correct. There is a problem relating to the scope of the system - what exactly is the scope of the system the constructs the instance? How tightly cross-connected do two partner systems need to be before "ISS" is appropriate instead of verified? But the proposed definition by Lloyd completely misses the point: The identifier was issued by the organisation identified as the scope on the role - so? Like, what does that mean, what assurance does it provide to anybody in any direction? The point here is to differentiate between things as reliable is primary identifiers, things that are well known, and things that are basically unreliable.--GrahameGrieve 04:54, 22 May 2007 (CDT)
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. It is still talking about Role and scoper. That needs to be generalized. How does it work for Acts? Should it not? Aren't the issues similar for Acts? If not, why? Gschadow 13:04, 20 May 2007 (CDT) 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. same deal as above; the point is that the system has verified this id, there's no scope for typos etc. But it's still not the primary identifier; things may be out of whack due to merging/linking inconsistencies, etc. The problem with defining the meanings of these in terms of the scoper is evident in this definition - the issuer was not the organisation identified (like, why not dude?), so the system confirmed the identifier with the issuer. So why is the scoper not the issuer, but more importantly, who cares? The root oid should still be consistently correct, whatever the scoper may or may not be, so the question is whether the system is sure about this or not.--GrahameGrieve 04:54, 22 May 2007 (CDT)
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. What is a "scoper" on an II? I think that Role verification should be an Act documented on the Role, not some use code on an II. Gschadow 10:15, 19 May 2007 (CDT) The purpose of giving this information on the id is that it gives an idea about the reliability and appropriate use of the id. Agree that if you want to talk about the verification process, you do it as an act. However, if all you want to do is give an idea of how certain you are that this id applies to this player, then you're fine.--Lmckenzi 15:18, 19 May 2007 (CDT) Problem is still that talk about Role may not belong here. I think that issue needs to be generalized such that it can be explained without reference to specific RIM concepts. 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. same comments. Actually, there is practical reasons to think that this use case is really only compelling for role, but there are use cases for act and entity as well.--GrahameGrieve 04:54, 22 May 2007 (CDT) 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. How is this important? How do I have to implement this correctly? Gschadow 10:15, 19 May 2007 (CDT) Generally, a Role.id is an identifier for the player in the role. Different player = different id. This is saying that the id is for the role itself, independent of player. There are use-cases where systems want to maintain roles independently of the people who play them and they need ids. The alternative is to have two ids on role, one for the role and one for the player of the role. In MnM conference call discussions, it was felt that this approach was cleaner.--Lmckenzi 15:18, 19 May 2007 (CDT) How can it be cleaner? The same attribute meaning two very different things? I think we need to contemplate very carefully if we want to allow Role instance to be re-used for different players and what that would mean. My original question still stands, how does the presence of this flag change what my implementation needs to do. That remains to be described very carefully. Gschadow 13:33, 20 May 2007 (CDT) I agree with Gunther on this one (I must not have been on that MnM call). If we want Ids on roles with different meanings, they should be different Ids. LeeColler 12:14, 21 May 2007 (CDT) see below for long skype thread on this subject. The upshot seemed to be that there is some confusion about the exact semantics of this, but solving it with this flag is just wrong.--GrahameGrieve 04:56, 22 May 2007 (CDT)
RW	Real World Identifier	This represents a potentially non-reliable identifier communicated for business purposes, but not deemed appropriate for matching purposes. Who decides that? From whose perspective is this? Is a US Social Security Number not a "real world" identifier? Is this going to tell me that I can't use an SSN for "matching"? What kind of "matching" is this referring to? How does this relate to the other values here, esp. BUS? Gschadow 10:15, 19 May 2007 (CDT) The decision is an opinion stated by the sender. They're essentially saying "this id isn't intended to be used for matching purposes". They can't prevent you from matching on it, but if you do so, you're doing so at your own risk. The primary use-case for ids is matching to other ids. However, sometimes ids are captured for reporting purposes, as descriptive characteristics, etc. We need to be able to communicate how a given identifier is intended to be used.--Lmckenzi 15:18, 19 May 2007 (CDT) All I want is such critical things to be defined very precisely. Now you say "the sender", the sender of what? If this is to be a property of an object, then there isn't just one "sender". How is this to be maintained? How does it interact with the other codes here? I think that this concept overlaps too much with USE. This is kind of like a some one else's business identifier that you are using. I would like to toast this one. --GrahameGrieve 04:59, 22 May 2007 (CDT)
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. This duplicates II.displayable functionality. How is this different from RW? What does a "provider" have to do in a discussion on II? How does "a class undergoes state transitions"? If you mean "the object", then, why would any identifier not "remain consistent as the object undergoes state transitions, including suspend, resume, revise, abort and complete"? What you really want to make a statement about here is that this may remain stable even accross multiple RIM Acts that are in SEQL relationships, you know, accross moods and updates. Gschadow 10:15, 19 May 2007 (CDT) Completely different from displayable. "often publicly exposed" does not say "is publicly exposed". A business id could be a GUID. The key thing is that it remains the same across revisions. It is differentiated from version and snapshot ids that change every time there is a revision of the object. They are NOT stable across multiple RIM Acts - we're talking about a single Act. For example - Prescription created, suspended, resumed, aborted would be a single Act, and each of the state transitions would have their own version id.--Lmckenzi 15:18, 19 May 2007 (CDT)
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 I don't think "jurisdictions" should be invoked in a discussion on such technicalities. "This type of identifier changes [not only] with each state transition on the object [but every time the object is updated." More would be needed to explain who's supposed to change these around in a loosely coupled distributed system. Perhaps needs to say that these should be thrown away by someone who does not intend to maintain version identifiers. Leaving those in objects as they get updated would cause chaos. Gschadow 10:15, 19 May 2007 (CDT) Jurisdictions is only mentioned because we're saying that not everyone will care about versions. Every time an object undergoes a state transition (including a revision that leaves the state unchanged), a new version is created. I've added a line that hopefully addresses the concern about treatment by those who don't support them.--Lmckenzi 15:18, 19 May 2007 (CDT) We could use the words contexts or implementations instead of jurisdictions - it would seem to invoke less issues.--GrahameGrieve 05:04, 22 May 2007 (CDT)
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. What is "a static model instance" in the data type specification? What "picklist" are you talking about? This is very confusing. Very specific rules about how these are maintained are required. It seems to me that these ids have no meaning outside of a specific external representation instance. They mean nothing in a database. Gschadow 10:15, 19 May 2007 (CDT) The use-case relates to static model instances. Understand the challenge of talking about them in an abstract data spec, but not sure how to get around it. I'm not sure what the picklist piece is about. Fundamentally this is about referencing a specific set of data elements from a specific version of an object. They definitely mean something in a database, as you'll need to be able to reconstitute exactly that version and set of data elements when validating a signature or reconstructing a view "as seen and approved" by a particular user. You can't show the current version or all information known, you can only show that particular "view".--Lmckenzi 15:18, 19 May 2007 (CDT) Propose that we drop the last sentence - I can't see that it helps with the definition at all.--GrahameGrieve 05:04, 22 May 2007 (CDT)
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. What is "a class that is not self defining"? Guys, stuff like this is loading amunition into Barry Smith's guns. Don't allow for such cheap shots. I disagree to the distinction Definition and Reference, and these things cannot talk about the Object, nor the identifier. They can only talk about an external representation of the object. This doesn't appear to be a property of an identifier at all. Gschadow 10:15, 19 May 2007 (CDT) Fixed "class". Agree that it's not strictly a property of the identifier, it is indicating how the identifier is being used in a given context. In one case, the identifier is being used to reference an object (possibly with validation support from other attributes). In the definitional case, it's being used to define an instance of an object (and you can be comfortable you've got the whole thing.--Lmckenzi 15:18, 19 May 2007 (CDT)
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. Watch your "class" vs. "object" vs. "view" language, please. I disagree to the distinction Definition and Reference, and these things cannot talk about the Object, nor the identifier. They can only talk about an external representation of the object. This doesn't appear to be a property of an identifier at all. Gschadow 10:15, 19 May 2007 (CDT) In an instance, we MUST be able to differentiate whether a particular XML fragment represents the definition of an object (I've got all the details) or a refence to an object that is further defined elsewhere that I'll need to retrieve the details if I don't have them already. That's what this is for. If you don't think it should be done this way, you need to indicate how it should be done.--Lmckenzi 15:18, 19 May 2007 (CDT)

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.

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

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