Difference between revisions of "Adding Record Target to ControlAct"
Rene spronk (talk | contribs) (add comments) |
|||
| Line 8: | Line 8: | ||
== Rationale == | == Rationale == | ||
Patient/Record Target is a key piece of information for all patient-specific interactions | Patient/Record Target is a key piece of information for all patient-specific interactions | ||
| − | * It is generally a key piece of audit information | + | * It is generally a key piece of audit information' |
* It can affect permissions in terms of data access and update capabilities | * It can affect permissions in terms of data access and update capabilities | ||
* It tends to be used for indexing data | * 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. | ||
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. | 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. | ||
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. | 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. | ||
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. | 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. | ||
| Line 20: | Line 23: | ||
== Issues == | == 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. | 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. | ||
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 | 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.. | ||
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. | 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. | ||
Revision as of 17:52, 14 April 2007
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
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.
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.
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.
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.
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..
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.
