This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Datatypes R2 Issue 57"

From HL7Wiki
Jump to navigation Jump to search
Line 36: Line 36:
  
 
{|
 
{|
|Issued|| Issued by scoper || The identifier was issued by the organisation identified as the scoper.  Mutually exclusive with Used and Verified.
+
|ISS|| Issued by scoper || The identifier was issued by the organisation identified as the scoper.  Mutually exclusive with Used and Verified.
 
|-
 
|-
|Verified|| Verified by scoper || The identifier was not issued by the organisation identified as the scoper, but the application has verified the identifier with the issuing authority.  Mutually exclusive with Issued and Used.
+
|VRF|| Verified by scoper || The identifier was not issued by the organisation identified as the scoper, but the application has verified the identifier with the issuing authority.  Mutually exclusive with Issued and Used.
 
|-
 
|-
|Used|| Used by scoper || The identifier was provided to the organisation identified as the scoper, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user.  Mutually exclusive with Issued and Verified.
+
|USE|| Used by scoper || The identifier was provided to the organisation identified as the scoper, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user.  Mutually exclusive with Issued and Verified.
 
|-
 
|-
|NonPlayer|| 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.
+
|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.
 
|-
 
|-
|RealWorld|| 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.
 
|-
 
|-
|Business|| 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.  
+
|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.  
 
|-
 
|-
|Version|| 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.
+
|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.
 
|-
 
|-
|View|| 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.
+
|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.
 
|-
 
|-
|Reference|| Reference || The identifier is being used in a class 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.
+
|REF|| Reference || The identifier is being used in a class 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.
 
|-
 
|-
|Definitional|| Definition || The identifier is being used in a class that contains enough information to completely define the object described by the class.  Mutually exclusive with Reference.
+
|DEF|| Definition || The identifier is being used in a class that contains enough information to completely define the object described by the class.  Mutually exclusive with Reference.
 
|-
 
|-
 
|}
 
|}

Revision as of 20:24, 30 April 2007

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 scoper The identifier was issued by the organisation identified as the scoper. Mutually exclusive with Used and Verified.
VRF Verified by scoper The identifier was not issued by the organisation identified as the scoper, but the application has verified the identifier with the issuing authority. Mutually exclusive with Issued and Used.
USE Used by scoper The identifier was provided to the organisation identified as the scoper, but cannot be verified. e.g. a Driver's licence entered manually into a system by a user. Mutually exclusive with Issued and Verified.
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.
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 a class 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 a class 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"

Resolution

Passed INM 30/4/2007: Motion to add use code called use to the II datatype

Still to do: define the terminology

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.