Difference between revisions of "Application Role"
Frankoemig (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. This includes [[Interaction]]s an application can send, as well as interactions it can receive. | + | {{INM Workitem}} |
| + | |||
| + | Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. This includes [[Interaction]]s an application can send, as well as interactions it can receive. | ||
| + | *An application role SHALL have the ability to execute the [[Receiver Responsibilities]] associated with received interactions. A receiving application role must be able to distinguish between the Receiver Responsibilities options and respond with the one that is the most appropriate for the particular interaction instance. In other words, the application role promises to execute the appropriate receiver responsibility in all circumstances where one of the underlying reasons is true. | ||
| + | **If it so happens that it can be demonstrated that for a given application, the reason for a given receiver responsibility will never be true, then one can still claim '''interoperability (but not conformance)''' because the application "promises to execute that receiver responsibility in all circumstances where that reason is true". | ||
| + | *A sending application SHALL have the ability to support all Interactions which may be returned as part of the [[Transmission Pattern]] once the application has sent an interaction. | ||
| + | |||
| + | Application Roles will form the basis for a suite of [[Conformance Statement]]s, in the same manner as was originally documented in the Version 3 Statement of Principles. | ||
| + | |||
| + | {{INM Motion|20070503 WGM Strawvote (8-0-2): to explore the adoption of the concept of Actor (as defined by IHE) as part of the dynamic model to describe the semantics of Receiver Responsibilities (the Interface Contract). Actor is confusing because of UML, redefine Application Role: Application Role is the set of supported Interactions, plus their respective Receiver Responsibilities (i.e. direct receiver responsibility, not conversation style). The set of supported interactions may include optionally supported interactions. Device.id is uniquely linked to a set of Application Roles. There may be no overlap in terms of supported interactions by the ARs.}} | ||
| − | |||
=== Notes === | === Notes === | ||
| Line 7: | Line 15: | ||
*One and the same interaction can be used by different application roles. | *One and the same interaction can be used by different application roles. | ||
*If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker. | *If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker. | ||
| − | *An Application Role | + | *An Application Role indicates support for one or more actors in a [[CPM]]. |
== Discussion == | == Discussion == | ||
| Line 16: | Line 24: | ||
Another aspect is the grouping of application roles due to their use: On the one hand they reflect the business roles, on the other they represent a hierarchy according to what needs to be implemented. It makes sense to define dependencies among different application roles, e.g. to support the "cancel admit notification tracker" only if the "revise admit notification tracker" role has been implemented/provided. The publishing database (PubsDB) currently provides a means to define the relationship between the application roles and events and interactions, but no recursive definition in form of a precondition. | Another aspect is the grouping of application roles due to their use: On the one hand they reflect the business roles, on the other they represent a hierarchy according to what needs to be implemented. It makes sense to define dependencies among different application roles, e.g. to support the "cancel admit notification tracker" only if the "revise admit notification tracker" role has been implemented/provided. The publishing database (PubsDB) currently provides a means to define the relationship between the application roles and events and interactions, but no recursive definition in form of a precondition. | ||
| + | :If application roles are too "atomic" in nature the uptake will be low, as it leads to long lists of roles that nobody will want to browse. The IHE Technical Frameworks contain "Actors", these are high level groupings defined in terms of mandatory and optional interactions. [[User:Rene spronk|Rene spronk]] 13:51, 18 Mar 2006 (CST) | ||
Currently, the application roles are a non normative part of the V3 standard. | Currently, the application roles are a non normative part of the V3 standard. | ||
Latest revision as of 09:53, 9 May 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.
Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. This includes Interactions an application can send, as well as interactions it can receive.
- An application role SHALL have the ability to execute the Receiver Responsibilities associated with received interactions. A receiving application role must be able to distinguish between the Receiver Responsibilities options and respond with the one that is the most appropriate for the particular interaction instance. In other words, the application role promises to execute the appropriate receiver responsibility in all circumstances where one of the underlying reasons is true.
- If it so happens that it can be demonstrated that for a given application, the reason for a given receiver responsibility will never be true, then one can still claim interoperability (but not conformance) because the application "promises to execute that receiver responsibility in all circumstances where that reason is true".
- A sending application SHALL have the ability to support all Interactions which may be returned as part of the Transmission Pattern once the application has sent an interaction.
Application Roles will form the basis for a suite of Conformance Statements, in the same manner as was originally documented in the Version 3 Statement of Principles.
Notes
- One and the same interaction can be used by different application roles.
- If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker.
- An Application Role indicates support for one or more actors in a CPM.
Discussion
The answer to “what are the business application roles” is in the heads and in the implementation specifications of the many experienced (V2) implementers and implementations. We need to tap into what has already been done – not the V2 standard, but how it is implemented by most V2ers most of the time. This is how we define “application roles” in the real world all the time.
The domain committees will have to use this experience and include business role based application roles (even if only as informative material) in their ballot material. In cycles subsequent to the initial ballot, the committees will define specific specializations or instantiations of the generic application roles defined above.
Another aspect is the grouping of application roles due to their use: On the one hand they reflect the business roles, on the other they represent a hierarchy according to what needs to be implemented. It makes sense to define dependencies among different application roles, e.g. to support the "cancel admit notification tracker" only if the "revise admit notification tracker" role has been implemented/provided. The publishing database (PubsDB) currently provides a means to define the relationship between the application roles and events and interactions, but no recursive definition in form of a precondition.
- If application roles are too "atomic" in nature the uptake will be low, as it leads to long lists of roles that nobody will want to browse. The IHE Technical Frameworks contain "Actors", these are high level groupings defined in terms of mandatory and optional interactions. Rene spronk 13:51, 18 Mar 2006 (CST)
Currently, the application roles are a non normative part of the V3 standard.
