Difference between revisions of "Datatypes R2 Issue 57"
Line 69: | Line 69: | ||
:::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. [[User:Gschadow|Gschadow]] 13:33, 20 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. [[User:Gschadow|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. [[User:LeeColler|LeeColler]] 12:14, 21 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. [[User:LeeColler|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.--[[User:GrahameGrieve|GrahameGrieve]] 04:56, 22 May 2007 (CDT) | ||
|-valign="top" | |-valign="top" | ||
|RW|| Real World Identifier || This represents a potentially non-reliable identifier communicated for business purposes, but not deemed appropriate for matching purposes. | |RW|| Real World Identifier || This represents a potentially non-reliable identifier communicated for business purposes, but not deemed appropriate for matching purposes. |
Revision as of 09:56, 22 May 2007
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
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.
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.
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)