#187 changes to AbstractOperationDescriptor/@AccessLevel

[Björn Andersen]

The attribute suggests these levels would be organised hierarchically, i.e. would be real supersets of one another. (Not that we explicitly defined that in 10207...)
We think, however, that there are privileges that, e.g., a clinician may have whereas service personnel may not - and vice versa. Consequently, an attribute does not suffice. We would need (at least) an element with cardinality 1..n (possibly even allowing for coded values) to grant an operation to more than one user group.

[Björn Andersen]

We either need to considerably extend the value set for, e.g. local user, or automation (i.e. no user at all) or allow for coded values to represent other access levels (possibly even unique to an RO).

[Stefan Schlichting]

Access level is really a category and not a hierarchy, but the categories may be subsets of each other, e.g. User and Clinical Super User.

Your example would be encoded with AccessLevel=CSUsr which would indicate that the Service Consumer should prevent access from a Service Technician.

If required: it is always possible to add multiple operations with different accesslevel or AccessLevel=Oth with some extension to model complex access level indications from the Service Provider perspective.

Proposal: Won't fix.

[Björn Andersen]

Introducing a coded value would also break backward compatibility for providers.