Adding Record Target to ControlAct

Proposal

Add an optional "Record Target" association to the ControlAct wrapper pointing to a Universal Patient CMET.

See Control Act for a discusion what partcipations or associations could (conceptually) be included in the ControlAct wrapper. This page contains a discussion of recordTarget in ControlAct only.

Rationale

Patient/Record Target is a key piece of information for all patient-specific interactions

• It is generally a key piece of audit information'
• It can affect permissions in terms of data access and update capabilities
• It tends to be used for indexing data

Rene: All of the above are not a reason to have it at in any particular part of the static model.

Lloyd: The ControlAct is the part of the static model where other information that affects the same processing decisions is located. The vast bulk of audit information, all permission information and most indexing information is found in the ControlAct. The reason is the desire to have common logic that performs these functions that doesn't require customization for each interaction it needs to handle.

Pat: This argument won't stop at the ControlAct. Implementers will suggest promoting such items outside even the TransmissionWrapper, into the SOAP Header of a Web Services Request, where they can be got at conveniently by integration infrastructure software. I don't think you can say "all permission information" is in the ControlAct, unless you can say for sure what all access control rules are going to be. Consent Directives may be specified down to a level of detail which requires parsing the payload in order to apply them, even if the patient ID were promoted to the ControlAct.

Lloyd: All permission information about the Event must by definition be in the ControlAct. The only part that is not in the ControlAct is the description of what the action is occurring to.

Rene: the word "must" is too strong. It all depends on ones definition of the controlAct and how detailed (or: semantically related) its participations and associations should be. Pat is right in that it could be argued that RecordTarget be part of the new Conversation Act, or be part of the SOAP headers.

At the moment, the path to patient information can vary from model to model and can be vastly different when dealing with query parameters meaning that writing common code to process audit, permission or indexing code becomes impossible. By placing Record Target on the ControlAct, it becomes possible to deal with these processes in a consistent manner.

Rene: using this argument, all kinds of commonly used payload participations and associations would end up at the entry Act of the static model (whatever that entry Act would be, given that the Wrappers R2 project may introduce a Conversation/Contractual Act as the static entry point). Whilst introducing a common XPATH expression to access the recordTarget, (a) for other things one would still have to go to the payload model, (b) it increases reliance on sender/receiver understanding the inheritance and propagation mechanism thereof in the models - the understanding of which is currently probably limited to a dozen people worldwide. From an implementation standpoint this is not desirable.

Lloyd:Receivers must understand propagation between the wrappers period. That is not optional. Placing patient in a consistent place for all models actually makes implementation easier, not harder. This isn't about "common usage", but rather about data that has specific uses other than merely pertaining to the payload.

Rene:In other words, your argument is that it's an attribute/class that is known to be used by a logical endpoint for things like routing, access control. In other use-cases this may be the postalCode of the patient, or the ward where the encounter is taking place, or the kind of modality associated with a Radiology report. But you're not suggesting to have those in the controlAct wrapper. We need a clear definition what (if we even accept recordTarget at the controlAct) should/could be moved up into the controlAct wrapper. Give me a clean definition and I might be persuaded.

Pat:If patient is not in consistent places amongst all models, I would suggest that putting patient in the ControlAct AS WELL is a poor resolution of that problem. If that inconsistency is accurate (in other words, the committees did the right thing in using inconsistent approaches to modelling the patient in their payloads) then the blanket inclusion of the patient in the ControlAct must be misleading. If that inconsistency is an accident, because of the independence of the committees, then I would like to suggest that it be resolved directly.

In addition, where a given ControlAct has multiple payloads (e.g. a query response), placing RecordTarget on the ControlAct means that RecordTarget does not need to be repeated for every payload repetition.

Rene: earlier on MnM has established that duplication has to be resolved ("optimized") by the ITS. From a pure abstract perspective placing RecordTarget at controlAct doesn't actually change anything.

Lloyd:From a physical perspective it changes things a great deal.

Pat:Presumably this benefit only applies when all payloads refer to the same patient. If they don't, then it makes no sense to put any patient IDs in the ControlAct, I guess.

Finally, the ControlAct is a logical part of the patient's record, in that it represents an event affecting information in the patient's record. Thus adding recordtarget to ControlAct is semantically correct.

Pat: Really? Surely this is only the case if the patient is simultaneously removed from the payload. Otherwise, it looks as though the patient has two participations in the act being messaged.

Issues

1. By introducing RecordTarget to the ControlAct, the question is raised about whether RecordTarget should be required (or even permitted) in payloads. There are varying opinions about how "complete" the payload should be independent of the ControlAct. Some would argue to duplicate the information in the payload, while others would argue to remove the recordTarget from the payload and rely purely on the wrapper. Resolution of this issue is fundamentally an MnM discussion. This has therefore been added to the MnM hot topics list as well.

Rene: disallowing it at the payload level would force all interactions to be about max. 1 patient. One CACT with multiple payloads, each having a different recordTarget (use-case: response to a query) would not be possible any more.

Lloyd: I didn't talk about cardinality. It's perfectly reasonable to allow it to be 0..* in the wrapper. If you're dealing with an interaction that is not patient or patient-group specific, obviously you wouldn't use it in the wrapper. However, cross-patient queries wouldn't fit any of the use-cases for having patient information in the wrapper, so this isn't an issue.

Pat: How would this proposal deal with a situation where multiple payloads refer to multiple patients, but the interaction requires maintaining the links between them?

2. Not all interactions are related to patients. It's not clear whether we should have distinct wrappers for patient-specific and non-patient-specific interactions at the international level

Rene: to me, another reason why we shouldn't do this..

Lloyd:In Canada we've made the choice to produce separate wrappers for patient-specific and non-patient-specific content, however that's in part due to the desire to have extremely rigorous constraints - we have a total of about 20 different wrappers when queries and registries are taken into account. The question for international isn't whether multiple wrappers are bad, it's a question of how specific we want to get at the international level.

Pat: And the multiplication of different wrapper types is in itself a problem, in my opinion.

3. It's not clear that full universal information is appropriate in the ControlAct wrapper. It may make more sense to constrain the wrapper to something like Identified-Confirmable, and allow reference to more detailed patient information in the payload where use-case demands.

Rene:We currently have the AttentionLine class in the Transmission wrapper which is explcitely intended to be used for routing/filtering purposes.

Discussion in MNM

Motion:

MnM recommends to INM that we create a new control act wrapper variant called TargetedControlAct which includes a recordTarget that points to R_Patient Identified-Confirmable. INM may wish to further consider the issue of non-living record targets and whether a new CMET and a redefinition of RecordTarget is justified.

We revise the definition of ControlAct wrapper to account for the introduction of RecordTarget to the ControlAct. Lloyd will submit text to include in the ControlAct wrapper introduction and walk through that will prevent any confusion relating to the scope of the control act wrapper. INM will refer any queries concerning the scope to Lloyd personally.

Committees will need to update their interaction definitions to specify the alternate wrapper if their use cases so require.

The text Lloyd will submit will include the ideas that the scope of the control act is limited to information that is meaningful across different types of control act and across all or most state changes, and is information that is specifically associated with the control act not the payload. Grahame / Paul K 5-0-2

Background Info

See CACT R2: In September 2006 INM has accepted a motion to allow context conduction between the controlAct wrapper and the payload.

Follow-up

2011-01-12: Waiting on InM to begin new wrapper project.