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

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