Adding Record Target to ControlAct

Proposal

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

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.

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.

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.

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.

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.