ActReference

What is an Act Reference

Act References have been defined by committees per MnM guidance like the following:

Issue

There are a number of issues:

• The only thing that really identifies this as an ActReference is the clone class name, violating the rule that Clone Class names don't add semantics.
• It could be argued the fact that since there is no other information in the class, aside from classCode, moodCode, or ID, it must be a reference.
• This doesn't satisfy all reference requirements.
  • How do I know how much of the Act and its descendent's are intended to be referenced?
  • How do I distinguish different versions of the same object?
  • How do I handle "snapshot" references?

Note that Datatypes R2 will add use to II. One of the use codes is Reference - so you could use this to make the Act as a reference. But I believe that this is wrong - it's the Act that is the reference, not the ID in the act. --GrahameGrieve 11:56, 3 May 2007 (CDT)

The above act, whatever its scope in terms of attributes, represents the same act as all other acts that have one and the same Act.id. It is the equivalent of all other acts that have one and the same id. Designating (in one way or another) that an Act instance is a "minimalistic version of a more fuilly detailed act elsewhere" (which to me is the real underlying use-case) may be a worthy use-case, but any receiver may have a business rule to go look for a more detailed act upon the receipt of an act that doesn't carry enough detail. What's the difference between 4 act instances that all have one and the same ID, but one has only the id attribut, the scond has id,code,status, the third that has id,code,status,value and a fourth that has all possible OBS attributes and associations? Which instances are references to "richer" versions? What is a "reference" for one application is the amount of detail required by another application.. Rene spronk 00:57, 4 May 2007 (CDT)

There is a difference between business identifiers (that identify the real world act), and instance identifiers that are bound to particular sets of information about the event. This distinction is not made (yet) when an act.id is populated. Where an identifier is being used as an instance identifier then it is meaningful and often useful to ask whether you are receiving the full instance, or a partial representation(reference). Once you have a copy of the full instance, you know that no information sent in a class with that identifier will be new to you. This can dramtically simplify processing. Once id.use is available it will be possible to establish when this instance identifier paradigm is being supported.Charliemccay 09:48, 15 May 2007 (CDT)

Discussion

This was discussed at great length in the Datatypes R2 taskforce. Generally the distinction between reference and fully populated act is a very grey. The standard practice in v2 is simple: get a segment with an identifier, merge it with all the information you already have, and work with that. The fact that it may be a reference or partially or fully populated is neither here no there. On the other hand, there is specific use cases where the clear intent is that the reference to the act is intended to be a reference, and there is no ambiguity.

The task force notes that this is absolutely not a property of the identifier itself - it is a simple identifier with the same intent. What changes is the intent of the context itself. And in fact, there are some use cases for providing an act reference without an identifier - say, providing a code and a date instead. So clearly using a property of II would be an inappropriate and incomplete solution. (II.use was proposed as a solution to this problem. But II.use was not approved by the taskforce (see Datatypes R2 Issue 57 for further details).

The taskforce felt that the appropriate solution to this is to use the updateMode attribute. The key to the choice of this solution is to note the interaction between the update modes A, D, U and the concept of reference. What sense would it make to say that something is an update and a reference? So UpdateMode is in the same space as Act-By-Reference, and actually reference is similar to saying "no Change". The old definition of updateMode in the MDF included some properties specifically aimed at resolving the issue of reference, and we can dig them out.

So, to review the use case: we want to send an act, label the act as a reference, and indicate which of the attributes of the act are provided to act as a key to resolve the reference, and which properties are merely to assist with display or other essentially cosmetic reasons.

We can solve this by adding two more codes to updateMode. One is "R": reference. With this you can label an association as a reference. The other is "K" - Key Value. You would label the important attributes with K to indicate that they are the ones that define the reference.

Here's an example.

<procedure updateMode="AR">
   <id updateMode="K"/>
   <reason updateMode="A"/>
      <diagnosis updateMode="REF">
          <id root="12345" updateMode="K"/>
          
     </diagnosis>
  </reason>
</procedure>

The procedure is sent "add/replace". it's given an id that is identified as a key - though this is superfluous. Then a reason is added, with a reference to an existing diagnosis using the id 12345 as a key, and a diagnosis code is added as a courtesy (but since it is not labeled as a key, it doesn't matter if the existing copy of the diagnosis has a different code.

Therefore the taskforce recommends that act references be designated by the use of updateMode using the old codes from the MDF, rather than using an II property.

Note that the taskforce did add two new properties to II for R2, and one is quite relevant to this discussion, which is scope - in what scope the identifier has - whether it identifies this particular view of the object (ie the exact set of information items describing the object - aka "shapshot"), this particular version of the object, the object itself, or a business process that is identified with the object.

Resolution

Accept the recommendation to use updateMode. This is now covered in the Core Principles ballot. As such, it is not really a hot topic any longer: Motion: 20080418 Lee, Austin 5,0,0